Labs: Securing Multi-protocol File Access (NFS/CIFS) on NAS (NetApp) Using Centrify and Windows Security Groups

Background

In the previous post, we discussed how to overcome identity limitations in NAS sharing scenarios.  In heterogeneous environments the main issue is about Identity - the filer is unable to consistently translate the Windows identity to a UNIX identity.  With Centrify Zones and the LDAP Proxy we solved the issue providing a unified identity consistently across Windows, Unix, Linux and Macs.

In Summary, here's what we accomplished:

The LDAP Proxy present's user information for the filer with consistency.  The UNIX information corresponds to what the AD user has in the Centrify Zone.

Now, we can let the NetApp filer do it's magic.  Let's look at a very simple example:

Testing Mixed Share Permissions

Set up the NetApp share

1. Create a new qtree
   qtree create /vol/vol0/mixed
2. Change the security model as mixed
   qtree security mixed
3. Export the newly created qtree
   exportfs -p rw /vol/vol0/mixed

Create a New AD Security Group for the Mixed Share Access

1. Open ADUC browse to an OU for groups
2. Select New > Group
3. Give it a name  (e.g. "Mixed-Share-Access")
4. Add a test user to the newly created share.

Publish the share in Windows

1. Open Computer Managemetnt
2. Connect to your NetApp filer
3. Navigate to System Tools > Shared folders
4. Follow the wizard to create your share
5. In the Share Permissions, remove Everyone and add your previously-created AD Group

Now you have:

• A CIFS share that is a shared folder protected by a Security Group in AD.  Access is governed by group membership and the permissions on the share.  NTFS permissions will be assigned at file/folder creation based on the user's identity.
• An NFS share that can be mounted from any Unix, Linux or Mac system;  UNIX file permissions will be assigned at folder/file creation based on the user's identity.  We'll leverage the NETGROUPS option with Centrify-exposed options to accomplish this.

Let's see this in action

Improvements

As outlined in the latter part of the video, there's definitely improvements that can be implemented:

• On the NetApp side, Kerberos can be implemented for additional security.  Remember that Centrify already provides "hands-off" Kerberos environment optimized for Microsoft's Kerberos.
• The AD Group used to control access can be UNIX-enabled, this opens the possibility of leveraging the group's UNIX identity as a group owner on the UNIX side.

Key benefits

• Process consolidation - now a single AD group can be leveraged to control access.
• Better Security - there's a better grasp on who has access to what.

Business Problems: Conquering the NAS multiprotocol (CIFS/NFS) file sharing in a mixed (Unix, Linux, Windows, Mac) environment using Centrify

Background

Network Attached Storage (NAS) is a key part of any enterprise today; they provide flexibility and an abstraction layer from an infrastructure perspective.  In the heterogeneous enterprise, the easy part is the infrastructure piece;  the hard part has to do with the diversity of platforms and the multiple file-sharing protocols in use.  This post and a series of labs will illustrate how leveraging Active Directory, Centrify Zones, the Centrify agent for UNIX, Linux & Mac and the Centrify LDAP Proxy we can ensure consistency with multi-protocol CIFS/NFS shares and enhance operational efficiency.

In previous posts, we have addressed how to to solve the consistency issue individually:

• Centrify and NFS Basics  (video lab)
• Centrify and Samba (CIFS) basics  (lab1, lab2)

This posts uses a NetApp filer as an example(*).  The concepts outlined here can be used on any NAS device that supports LDAP.  We will assume that you understand that the fundamental problem is how to solve the issue of identity across multiple platforms and how we accomplish that with the Centrify Agent and Active Directory (I highly recommend that you read the previous links).

The Issues (or variations of it)

• We have a NAS device, we integrated it with AD and it works great as long as the user is performing file operations on Windows.  However, we have to keep separate NFS shares.  We also have to manage permissions in multiple groups (Windows or UNIX) and that takes a lot of effort.
  Note, in my example with NetApp, the appliance does a great job at discovering LDAP servers:
  
  netapp1> Sat Jul  5 11:26:52 EST [netapp1:auth.ldap.trace.LDAPConnection.statusMsg:info]: AUTH: TraceLDAPServer- AD LDAP server address discovery for CORP.CONTOSO.COM complete. 2 unique addresses found.
  
  However, although it can resolve the AD portion, it is plain wrong about the Unix UID:
• We have a multi-protocol share (CIFS/NFS), everything is great on Windows, when the user wants to access their files over NFS he has to call to have the file/folder ownership taken care of
• We are tired of having to resolve file ownership issues.  Our organization is globally very diverse and each time we have a new visitor we spend significant amount of time helping them get access.
• We have a combination of Unix, Linux, Mac and Windows users and although we had it down in individual servers, when we moved to filers now we have all these new issues.
• I have a filer in my environment and we have Centrify as well, I know it can help but I don't now where to start.

Example of one of the issues

Let's look at an example.  In my environment with a domain-joined Netapp the appliance does a great job at discovering LDAP servers (this happened once I searched for one of my users):

netapp1> Sat Jul  5 11:26:52 EST [netapp1:auth.ldap.trace.LDAPConnection.statusMsg:info]: AUTH: TraceLDAPServer- AD LDAP server address discovery for CORP.CONTOSO.COM complete. 2 unique addresses found.

netapp1> wcc -s george.constanza

(NT - UNIX) account name(s):  (CORP\george.constanza - pcuser)

        ***************

        UNIX uid = 65534

        NT membership

                CORP\george.constanza

                CORP\UNIX-Model-Samba Users

                CORP\UNIX-Model-All Users

                CORP\UNIX-Model-dbaadmin

                CORP\Domain Users

                CORP\UNIX-Model-Sysadmins

                CORP\UNIX-Model-webadmin

                CORP\UNIX-Model-All UNIX Groups

                BUILTIN\Users

        User is also a member of Everyone, Network Users,

        Authenticated Users

        ***************

This is great from a Windows perspective, however, look at the Unix UID (65534), when you look at the options, this means that the user is being assigned a "nobody" user from a UNIX perspective.  We can further confirm this with this command:

netapp1> wcc -u george.constanza

no passwd entry for george.constanza

The way I have my system configured, although I can derive the user's identity leveraging the DCs, I can't see the user's Unix identity.  It is stored in the zone. See the output from a centrified system:

george@ubu1:/etc/centrifydc/openldap$ adquery user george.constanza -A

unixname:george

uid:1149240406

gid:1149240406

gecos:George Constanza

home:/home/george

shell:/bin/bash

auditLevel:AuditIfPossible

isAlwaysPermitLogin:false

dn:CN=George Constanza,OU=Staff,DC=corp,DC=contoso,DC=com

samAccountName:george.constanza

displayName:George Constanza

sid:S-1-5-21-2180375406-786980114-1643973036-1110

userPrincipalName:george.constanza@corp.contoso.com

canonicalName:corp.contoso.com/Staff/George Constanza

passwordHash:x

accountExpires:Never

passwordExpires:Wed Aug 13 11:28:48 2014

passwordWillExpire:39

nextPasswordChange:Thu Jul  3 11:28:48 2014

lastPasswordChange:Wed Jul  2 11:28:48 2014

accountLocked:false

accountDisabled:false

zoneEnabled:true

unixGroups:dbaadmin,george,webadmin

memberOf:corp.contoso.com/UNIX/Provisioning/UNIX-Model-All UNIX Groups,corp.contoso.com/UNIX/Provisioning/UNIX-Model-All Users,corp.contoso.com/UNIX/RBAC/UNIX-Model-Samba Users,corp.contoso.com/UNIX/RBAC/UNIX-Model-Sysadmins,corp.contoso.com/UNIX/UNIX Groups/UNIX-Model-dbaadmin,corp.contoso.com/UNIX/UNIX Groups/UNIX-Model-webadmin,corp.contoso.com/Users/Domain Users

Our goal is to make sure that our filer (or application) gets the correct Identity information for the purposes of proper file/folder ownership, access and permissions.

Who's affected

As you can see, the variety of problems outlines have multiple constituents:

• Security needs to make sure that users have access to what they need and to comply with policies
• IT (business) need to make sure that users can do their jobs
• IT (operations) wants to be efficient and make sure that an army of people is not needed
• The End User just wants to get their job done

As with all Business Problems, we'll use the Plan, Do, Check, Adjust methodology.

Planning

As discussed in previous posts, the key to this issue is Identity.  In this case, the NAS appliance needs to know not only the user's AD information, but the extended attributes (RFC2307) like unixname, UID, GID, Home, GECOS, Shell, etc., and unlike other approaches, Centrify stores this information in the zone.  This makes the solution more flexible because an AD principal can have multiple Unix identities.

Note:  If you've read this blog, you know that I've been very vocal about overrides (what enables multiple identities and roles).  Every process needs to have constraints; constraints make solutions simpler.  Having a normalized UNIX namespace is the goal and destination of any enterprise, even if Centrify allows you to put off this goal.  

Identity and Access Planning

1. Do the best you can to have a normalized namespace.  Leverage Centrify's ability to assign users a unique UID by generating it from the AD SID (using Centrify or Apple's Scheme).
2. Perform a migration if necessary (this post talks about strategies and Centrify tools for that purpose)
3. Leverage the power of hierarchical zones:  provision all identities at the top-most zone.  This will ensure that all pertinent systems will know the user's identities.
4. Continue to enforce the least-access principle:  Use the "listed" role to make users known to the systems (e.g. the LDAP proxies) and ensure that they can't sign-in to the systems.

Planning your LDAP Proxies

The Centrify LDAP proxy leverages the Centrify client (adclient) to present AD information to clientless devices or programs.  The benefits of leveraging the proxy are:

• It flattens AD for the application:  depending on the enterprise, AD can be complex.  There may be multiple forests, child domains, one-way, two-way trusts, etc.
• It leverages the agent's built-in capabilities:  optimal DC selection, site-awareness and offline cache.

Plan for high-availability:  the NAS (or application) is going to require redundancy, plan to deploy and configure multiple proxies.

Plan for confidentiality:  make sure that only authenticated connections over secure transports (TLS, SSL, etc) in case your appliance or application does not do it natively.

Plan for high-performance:  As always, have NSCD on the Centrified system, and plan for co-location near the appliance, application and be close to Global Catalog servers in complex environments.

Plan for your file-sharing use case

This section varies based on what you want to accomplish.  Planning for home directories is not the same as planning for a workgroup share.  

Implement (Do)

1. Unix-enable all your relevant users (you don't need to Unix-enable users that won't ever access via NFS).  You can do this manually, with ZPA or with your own IdM solution.   
2. Assign roles as required:  keep the least-access principle intact by leveraging the "listed" role.
3. Install the LDAP Proxy(es):
1. Copy the Centrify LDAP proxy binaries to the platfrom.
   e.g. for Ubuntu on 2014:  centrifydc-ldapproxy-5.1.3-deb5-x86_64.deb
2. Log in and install the package
   e.g. dpkg - i centrifydc-ldapproxy-5.1.3-deb5-x86_64.deb
   The LDAP proxy binary is on /usr/share/centrifydc/libexec
   The config files and schemas are in /etc/centrifydc/openldap
   The LDAP utilities (like ldapsearch)  are on /usr/share/centrifydc/bin
3. Modify the RFC 2307 map
1. Edit the /etc/centrifydc/openldap/rfc2307.map file
2. Add the following line (for NetApp compatibility):
   # Added for NetApp
   posixAccount.userPassword: _userPassword
4. For testing only, start slapd manually:
   dzdo /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://ubu1.corp.contoso.com
5. Check that the proxy is running
   $ ps -ef | grep slapd
   root     23192     1  0 Jul04 ?        00:00:00 ./slapd -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://ubu1.corp.contoso.com
6. Verify that the proxy is responding to queries (e.g. check the Administrator account)
   $ /usr/share/centrifydc/bin/ldapsearch -h ubu1.corp.contoso.com-x -b "dc=corp,dc=contoso,dc=com" "(cn=Administrator)"
   # extended LDIF
   #
   # LDAPv3
   # base <dc=corp,dc=contoso,dc=com> with scope sub
   # filter: (cn=Administrator)
   # requesting: ALL
   # with pagedResults control: size=100
   ## Administrator, Users, corp.contoso.comdn: cn=Administrator,cn=Users,dc=corp,dc=contoso,dc=comaccountExpires: 0
   (output truncated***)
4. Configure your NAS appliance (e.g. on NetApp Ontap v 8.1.2)
1. Housekeeping:  Make sure that the name of the appliance is resolvable (add an A record for it) and that all Centrified systems, Windows Systems can resolve it.  The NetApp system should resolve all systems as well.  E.g.
   netapp1> ping ubu1
   ubu1.corp.contoso.com is alive
   netapp1> options dns
   dns.cache.enable             on
   dns.domainname               corp.contoso.com
   dns.enable                   on
   dns.update.enable            off
   dns.update.ttl               24h
2. Housekeeping:  Make sure that CIFS and NFS are licensed, enabled and the NetApp filer is joined to the domain.  (use the license command, the cifs setup command )
3. Verify that there's a computer object for the netapp device and that you can (as a Domain Admin) connect to it via Computer Management.  E.g. using ldapsearch:
   george@ubu1:/etc/centrifydc/openldap$ /usr/share/centrifydc/bin/ldapsearch -h
   ubu1.corp.contoso.com -x -b "dc=corp,dc=contoso,dc=com" "(cn=NETAPP1)"
   <truncated>
   # NETAPP1, Appliances, corp.contoso.com
   dn: cn=NETAPP1,ou=Appliances,dc=corp,dc=contoso,dc=com
   <truncated>
4. Optional:  Make sure that Domain Administrators are not mapped to root the NetApp filer:
   netapp1> options wafl.nt_admin_priv_map_to_root off
5. Configure NetApp to use the LDAP Proxy (Example corp.contoso.com;  ubu1)
1. Set up the LDAP base container
   netapp1> options ldap.base dc=corp,dc=contoso,dc=com
2. Set up the LDAP server(s) to be used by the NetApp appliance
   netapp1> options ldap.servers ubu1.corp.contoso.com
3. Set up the name of the Active Directory Domain
   netapp1> options ldap.ADdomain corp.contoso.com
4. Map the userPassword attribute to avoid null results
   netapp1> options ldap.nssmap.attribute.userPassword cn
5. Enable LDAP
   netapp1> options ldap.enable on
6. Modify the /etc/nsswitch.conf to make LDAP the first source for user, group and shadow entries.
   netapp1> wrfile /etc/nsswitch.conf
   hosts:  files  dns
   passwd:  ldap files
   group: ldap files
   netgroup:  files nis
   shadow:  files nis
7. Verify the results
1. Query and note the UID from Windows
   wcc -s jerry.seinfeld 
2. Query and note the UID from UNIX
   wcc -u jerry.seinfeld
3. Advanced query using NSS
   priv set diag
   getXXbyYY getpwbyname_r jerry.seinfeld
   
   Compare the results with the zone information.  At this point it should match the UNIX identity on Access Manager

Check the Results

To verify the results, use a multi-protocol (CIFS/NFS) share and make sure that the identity information is consistent.

1. From a Windows system in the target domain, map or browse to the share via CIFS.  Create a file.
2. From a Unix/Linux or Mac system, mount the share as an NFS mount and issue the ls -la and ls -lan.  Compare the results from before.

Adjustments to the Implementation

Adjustments are based on your existing environment, however, based on ours here are some key modifications:

• There's only one LDAP proxy, we need several for high-availability
• The LDAP Proxy is accepting anonymous connections, we need to make sure that only authenticated connections are accepted.
• Ideally we would use Secure LDAP or implement TLS or IPSec for additional confidentiality controls.
• Operations needs to monitor the health and status of the LDAP Proxies

Lab Videos

What you'll need to follow along:

• Active Directory
• Centrify Standard Edition
• A Centrify zone
• Client for Unix, Linux or Mac
• Centrify's LDAP Proxy
• A Multi-protocol filer (we'll use NetApp's  ONTAP Simulator)

Installing, Configuring and Testing the Centrify LDAP Proxy

Configuring the NetApp appliance to use the Centrify LDAP Proxy


Verifying the NetApp CIFS/NFS share provides consistent identities

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

Security Corner: Opinion about Synchronization of UNIX identities and Password Management

Background

We have been recently been asked questions from prospects to contrast Centrify solutions versus solutions that synchronize identities in the local system and if Password Management is the right approach for Privilege Management.

How Synchronization Works

Synchronization varies between providers but typically it works this way:

There is an authoritative source for an object (user, file, attribute, etc.) this is considered the Master copy.  Then there are the targets that need copies.
Solutions like BMC ControlSA implement synchronization this way;  there is a server or a source that provides master copies, and in the case of UNIX, the replicas are propagated to UNIX/Linux Systems. In the case of users, they are replicated into the /etc/passwd file;  in the case of groups, into the /etc.groups file;  In the case of passwords, the /etc/shadow file.

Problem solved:  Identity is Centralized....?

Wait... let's examine this closely.

• Synchronization can break (due to many things), this means that a compensating control needs to be implemented to make sure that replicas are in sync with the master.  At this point, you have to deploy a monitoring agent to make sure that all your end systems are properly synchronized (detective);  also people or automation has to be implemented to fix it (corrective).
  Centrify approach:  We talk directly with AD and use NSS, so nothing has to be sync'd.  Can we go offline?  Yes.  But most likely it has to do with someone making a change (maybe moving to  a new subnet not registered in AD) and even there we have the cache.
• Password Synchronization weakens confidentiality.  This is because passwords have to be read from an authoritative source and synchronized with the master server or with the agents.  If your users live in AD, that means that compromises need to be made (reversible encryption) just to make sure that your synchronization works.
  Centrify offers Password Synchronization, but we will be the first to tell you that it is just a competitive feature. We do inline transactions using Kerberos, so no passwords are synchronized or in the clear.  It's all ticket-based.
• The master copy is another directory.  This means more assets, people and processes.
  Centrify uses AD.  No duplication of capabilities.
• Identity Synchronization is NOT authentication.  In the scenario described below, authentication still happens locally since even passwords are synched locally.  This is why you will see solutions like BMC combined with other solutions; they can't solve the other side of the puzzle.
  With Centrify, authentication is implemented as a PAM module on UNIX and it uses our MIT Kerberos-based libraries that have been extensively tested against Microsoft's Kerberos Implementation.
• Identity Synchronization is NOT privilege management:  Privilege Management is about limiting access, privileges, across multiple platforms, getting timely information about who has access to what.
  The Centrify Base Agent provides a robust RBAC model that not only works on UNIX/Linux, but in Windows as Well.
• Identity Synchronization is NOT Governance:  Governance is about being able to separate the people who set the rules from the people that perform the operations.  At the Master copy level this may be possible, but not at the system or end-point level.
  With Centrify, delegation is possible by leveraging AD objects.  Discretionary Access Control Lists allow us to separate the functions of a person that needs to join systems, vs. a person that defines roles and rights.

Synchronization may be inevitable in complex organizations, but when it comes to UNIX/Linux identities with Active Directory it does not have to be that way.

How Password Managers Work

This has been an interesting topic as of late.  The whole capability has the key in the name:  password Management (or shall we say Shared Account Password Management?).  The whole premise is that there's a privileged account (or a service account) that needs to be controlled.

The great thing about password managers is that they can be the faster path to compliance (like a failed audit), but they don't really solve the Privilege Management issue.  They are absolutely part of the solution, but help 20 to 25% of the use cases; the rest of the cases you should be using the principle of least privilege.

Password Managers offer capabilities like:

• Robust Encryption
• Customizable Workflows
• Web Interfaces
• Quick ways to keep auditors happy
• Many password managers provide session management and can capture and replay the session

Problem solved:  Privilege Management is conquered?

Shared Account Password management is not the same of Privilege Management, it's just a subset of capabilities needed for proper privilege management.

Let's look closely:

• The privileged shared account is still used.  It is still root or oracle that are being used;  the only thing that happened is that there's a traffic cop (the password manager) that via the pre-configured workflows allows to check out the password for the account in the target system.
  With Centrify, this is not the approach;  you can grant the individual (AD user) the proper rights; be it a super user or a person that can run only one privileged command. This is implemented with a modified version of sudo (dzdo). You can control how they access the system as well.  And works on Windows.
• Since the password manager is so important, now it has to be highly available = More costs
  With Centrify, we leverage the existing investment in AD.  Reuse vs. New CapEx.  What's easier to justify?
• Password Managers are intermediate systems or proxies.  What if the system accessed directly?
  With Centrify, the adclient is loaded on all managed systems, therefore the rules are enforced end-to-end.  If John Doe can't log in to  Web system, he just can't.  Also, forget about the session capture data.
• The fact that the shared privileged account is managed, does not mean that access is controlled at an individual basis.
  In an environment that follows proper security access management practices, it's still required to know who has access to what and what can they do.
  That's why Centrify's approach is identity-based (leveraging the AD account), not only access can be limited, but privileges can be set as well.
• Perception of Security:  A password manager does not secure the data in the target system.  Don't forget the reason why you're doing security in the first place:  to protect sensitive data.  The problem is not the password, in the context of identity it's implementing strong access controls.
  With Centrify, the local agent will make sure that only folks that are authorized to access the system will be able to, and it can't be circumvented.
• You are affecting the user's productivity:  Ask any vault or SAPM user and they will tell you that they hate it.
  With Centrify, users sign in to the target system (regardless of using SSH, console, RDP) with their AD credentials and are able to perform privilege elevation.  As a matter of fact, Vault makers don't disagree with this approach (otherwise why would they license this?)
• Per-User Costs:  A sad situation for any prospect is that vaults have a complex licensing scheme. The vault needs to be bought (+ additional vaults for HA), this is CapEx; Now add a per-user cost for all managed systems (UNIX or Windows)!!!  (and I have yet to get to support/maintenance costs or complexities due to geographical deployments)
  With Centrify, we provide PERPETUAL per system licensing.

SAPM solutions are definitely necessary in complex enterprises.  In Unix there's single-user mode, in Windows there's the local Administrator account and finally on there's the issue of network appliances.  They can also be a quick solution to a tactical security issue.  This is why Centrify is looking at this capability very closely.

Note (May 2015):  Centrify has released their own SAPM solution; this means that now they can offer both the Least Privilege and Shared Account approaches.




In my personal opinion, I also think that since Password Managers are typically appliances, it's easier to say, well, "at least we have something to stare at" effect is present.  Software-based solutions are harder to "get" - We go through this every day:
- Prospect:  "Where is the server?"
- Centrify:  "No sir/madam, there's no server, you already have the infrastructure in place."
- Prospect:  "But where are you synchronizing?"
- Centrify: "No Ma'am, identities live in AD."
- Prospect: " But where do you put the sudoers file?"
- Centrify:  "There's no sudoers.  We leverage AD and our technology"

People are more interested in how we do things than the fact that we are making things simple.  Most people can't believe it.  Just like magic.


The HUMAN Problem

Another challenge is that a lot of UNIX administrators have not learned to let go of the root account and other service accounts.  In looking at how some our existing customers use their systems today, it's very common to see them log in with their AD account, and the first command is dzdo su - or dzdo su - oracle, etc;  what this means is that they see a vault as the easiest way to maintain the status quo.

This problem exists on Windows as well.  It is quite common for admins to camp on different workstations or RDP sessions with their "-a" accounts.  This is a poor behavior that must be eliminated by imposing privilege elevation on Windows too.

Lab 16: Configuring ZPA for Automatic UNIX Group Provisioning

Background

Posting:  http://centrifying.blogspot.com/2014/03/basics-automatic-unix-profile.html
Automatic Provisioning for Users: http://centrifying.blogspot.com/2014/01/labs-centrify-zone-provisioning-agent.html

Part 1

1. We configure grant the proper rights to the Centrify ZPA AD service account
2. We create the Source Group
3. We create a test group (UNIX-HQ-webadmin) and nest it to the source group.
4. We test and verify that automatic provisioning is working

Part 2

1. We verify that add/moves/changes are working as expected.
2. We modify the UNIX group profile with account overrides
3. We modify the UNIX group provisioning to automatically set the unix name and GID based on our needs.
4. We add the dbaadmin group.
5. We verify that regardless of the membership, only the users who have been granted rights to the system are the ones in the NSS group.

Basics: Configuring the Centrify Zone Provisioning Service for Automatic Secondary UNIX group provisioning

Background

In a previous posting we discussed how to implement automatic provisioning of UNIX user identities using Centrify's Zone Provisioning Agent (ZPA).
As part of BP#2, one of the key requirements was to implement a provisioning model for secondary UNIX groups and to make it resemble the existing one for users.
This capability consists in the automatic creation of the secondary UNIX group as well as the lifecycle maintenance of members (add/moves/changes).

All the principles applied in the basic posing about ZPA apply here, but in the context of UNIX secondary groups.  Let's apply the Plan-Do-Check-Adjust methodology.

Planning for Secondary Group Provisioning

Is the secondary group needed
The first place to start is to ask "Why is this secondary group required?" -  remember that with Centrify there is no need to have these groups for Access or Privilege purposes, Zones and RBAC take care of all that. In these exercises, the typical answer "Because that's the way is done" is not a good answer so you may have dig deeper.

Naming Conventions
The same rules of UNIX systems apply here as well, but they are a bit more stringent;  the 8 character limit for users is platform-dependent;  the UNIX group case, it may be more of a hard requirement.

Active Directory
Basically the way UNIX Groups work in Centrify is as follows;  there is a security group in AD for each secondary group in UNIX;  the memberships are handled from AD (the process consolidator and time saver), however, governance and processes have to be taken into account.  Questions such as:

1. How are AD Security group are requested today?
2. How is the membership lifecyle managed (add/moves/changes)?
3. Are group memberships subject to any attestation process?

Need to be understood and agreed upon.  

Group Merging

Group Merging is the ability to mix members from other Name Server Switch groups (like /etc/group) with UNIX Enabled AD groups. For example, if an application requires the enumeration of all the members from the software group (UID 200) and the application uses local users (e.g. like the db2inst account) and AD users (like jessie.matthews), then this feature needs to be implemented as well.

Implementing (Do) Secondary Group Provisioning

The process is as follows:

1. Make sure the service account used for ZPA has the proper delegation to add/remove/modify group profiles.  This is done through the Delegation Wizard of the zone.
   
2. An Active Directory "Source" Group is created.
3. ZPA is configured to look at that group as the source group.  For consistency, this group is stored in the OU designated for provisioning 
4. The rules for GID are set, the options are:

• An unique value generated from the group's System ID (SID)
• The RFC 2307 attribute (has to be populated in the object manually or programatically)
• Using the defaults set in the zone (Group Defaults tab)
• Using Apple's scheme (this is new for version 2014)
  
5. The naming rules are set (truncation, character sets, prefixes, etc)
6. Once this is set, ZPA is ready to provision UNIX groups.

Verifying the Implementation (Check)

Verifying group creation:

1. Restart ZPA (so the new zone provisioning configuration is processed)
2. Create an AD Security group.
3. Nest the group (make it a member) of the source group in the previous step.
4. Wait the ZPA refresh cycle or restart the service.
5. Verify that the new group exists under Zone > UNIX Data > Groups.
6. Verify that the group exists in the adequate UNIX systems.  There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
7. To verify the group's deletion, just remove the AD group from the source group and cycle ZPA;  the UNIX group will be removed from the zone.

Verifying Add/Moves or Changes

1. Add a user to the previously provisioned group
   Note:  this user needs to be at least listed in the system, otherwise he/she won't show. For example, if the user has a UNIX identity, but only has access to web servers, the user will not show in the Database Servers by virtue of the access rules enforced by Centrify.
2. Wait the ZPA refresh cycle or restart the service.
3. Verify that the user's UNIX name is in the list of users for that group.
   There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
4. Remove the user from the AD group (go to step 2) and in step 3 verify that the user is gone.

Performing Adjustments

Adjustments may vary depending on the results.  They can be:

• Adjusting how the GID is generated (or reviewing the provisioning process)
• Adjusting how the UNIX name of the group is generated.
• Adjusting group merging options.

Basics: Automatic UNIX Profile Provisioning Using Centrify's Zone Provisioning Agent

Background

In a previous posts we discussed what's in a UNIX profile, we have also discussed the concepts behind Centrify Zones, how Active Directory users can be UNIX-enabled using Centrify and what are some of the considerations and strategies for UNIX identities;  the problem has been that our labs have been focused in manual Identity manipulation.

The reason for this is simple:  understanding the basics is establishes the best foundation to address complex issues; but since we have gone over man manual scenarios, in this posting we will discuss automatic provisioning with the Zone Provisioning Agent (ZPA) utility.  The rest of the labs will use ZPA with a rationalized namespace.

Why Exceptions are Bad

In IT infrastructure, Security as well as in Identity and Access Management, designers need to strive for standardization and simplicity; sadly the reality is that organizations are complex today because problems are addressed in a reactive matter and rarely the root cause of issues are addressed, instead, organizations throw technology and resources at the problem.

Getting to a standard Identity Provisioning process is hard and the most challenging part is the ability to make the process standard and repeatable enough that exceptions are almost eliminated.   Exceptions introduce overhead and unnecessary risk; any system administrator with a certain degree of experience knows this and the sad thing is that some of them have figured out that complexity keeps them employed and enjoying the status quo.

Exceptions = More complexity = More stress = More work = More cost = Lower Satisfaction

In addition, to be completely fair, not all organizations can afford to completely aim and then shoot.  This is why solutions need to allow a certain degree of flexibility.

Centrify Zone Provisioning Agent

The Zone Provisioning Agent (or ZPA) is a utility included with Centrify Standard Edition that allows the automatic provisioning of UNIX identities leveraging Active Directory Security groups.
Yes, we get to reuse the same process again.
ZPA waits a preset number of minutes and searches in Active Directory for provisioning groups, and based on the zone defaults, will automatically UNIX-enable a user.

ZPA is implemented as a Windows Service or it can be run as a command utility called zoneupdate.exe.
Zoneupdate provides an interface to work with scripting or Identity Management solutions.

Like any other solution, ZPA has to subscribe to the Plan-Do-Check-Model.

Planning for ZPA

• Understand the impact of ZPA - once a zone has been enabled for automatic provisioning, AD users can't be UNIX-enabled manually, overrides are still possible at the zone, child zone and system levels.  The unavailability of manual provisioning, stresses that the process has to be clean of major exceptions.
• Determine how you're handling the Unix Name (RFC 2307 uid attribute).  This is important because some UNIXes need to be enabled for long name support and you may have naming conventions to consider.
• ZPA allows to handle any exceptions on the settings for the UNIX name.
  
• ZPA can use any attribute stored in the user object as the RFC2307 uid field, therefore if you have any scripts, IdM solution, etc that make transformations and write them into this field, they can be leveraged by zpa.  The default is the AD username:  ${u:sAMAccountName}
• ZPA requires a master provisioning AD security group per zone;  this means that we need to create and populate an AD Security group with the users that require provisioning.
  Sample Design (Nested Groups):  
  You can leverage Active Directory group nesting to kill two birds with one stone.   For example:  Jeremy is a member of the UNIX Database Servers Users group;  since this group grants the role in the appropriate number of systems, we can safely assume that he requires a UNIX profile, so if we have a Provisioning group called UNIX All Users, all we need to do is nest the role-granting AD group in to the provisioning group.
  
  
  This design simplifies operations because either manually, programmatically or by virtue of using an Identity Management tool, adding or removing the user to the role-granting group, has the effect of provisioning or deprovisioning access.
• ZPA high-availability:  All services need to be planned with HA in mind.  Running multiple ZPAs is not uncommon.
• Planning for Exceptions:  In this model, Centrify allows for identity overrides at the child or system levels.
• Planning for Migrations from existing Manual to ZPA zones:  In this case, the brief moment in which the accounts won't be available has to be accounted for.
  All users will lose their UNIX identities until the next polling interval kicks-in.  If well planned, this should be negligible in a medium to small environment.

Implementing ZPA (Do)

To Implement ZPA, at a high level:

1. Create the Provisioning group and populate it with the appropriate users and/or groups.
   If using the model outlined above, nest the role-granting groups into the provisioning group.
2. Request an Active Directory service account to run ZPA.
3. Delegate the proper permissions for Users (or Groups) for ZPA to be able to perform the functions desired.
4. Install ZPA in a highly-available system.
   Note:  If it hasn't been done, your existing Access Manager consoles have to be extended with ZPA setup to have the Provisioning tab enabled.
   
5. In Access Manager Configure the zone for automatic provisioning (if this zone had users, the UNIX-identities will be deleted)
6. Configure the account and the polling interval for ZPA
   (You may need to make sure that the service account has the proper log on locally rights)
7. When the service starts, all identities will be provisioned.

Verifying the Implementation (Check)

1. In Access Manager, verify that all UNIX Identities are accounted for.
2. In the UNIX systems, make sure that after an adflush all users for the corresponding system are accounted for.
3. Add a user to one of the role-granting groups.  Trigger a polling interval.  Verify that the user has a UNIX identity.
4. Remove the user from the role-granting group. Trigger a polling interval.  Verify that the user has lost his UNIX identity.

Adjusting the ZPA Implementation

There are multiple reasons to adjust a ZPA implementation, but the most common are:

• Provisioning SLAs:  Provisioning is composed of multiple parts:  from user creation or provisioning, to workflow/approvals, AD-replication, cache-flush intervals and now ZPA.  The polling interval may need to be adjusted for Service Level Agreements.
• Performance:  Network, domain controller availability, etc.
• Availability:  Redundancy, etc.

Videos on setup here: http://centrifying.blogspot.com/2014/01/labs-centrify-zone-provisioning-agent.html

Zoneupdate Help

Usage: ZONEUPDATE [options] zone1 [zone2 zone3...] Options

/z|SourceZone:Path  
Copy user attributes from the source zone (specified in canonical name format, for classic zone only).

/d|Domain:DomainName
The FQDN of the target domain.

/dc|DomainController:DomainControllerNameThe target domain controller to connect to.

/u|UserSource:ADGroup[@domain]

The AD group used to populate the users in the zone.

/g|GroupSource:ADGroup[@domain]The AD group used to populate the groups inthe zone.

/uu|UserUid:<Option>
The method to generate the UID for a user profile. Option can be one of the following values. Auto is the default if this option is not specified.

/us|UserShell:<Option>

The method to generate the UNIX shell for a user profile.

Option can be one of the following values. 

/uh|UserHomeDirectory:<Option>

The method to generate the home directory for a user profile.

Option can be one of the following values. 

/uc|UserGecos:<Option> (For hierarchical zone only)

The method to generate the Gecos in a user profile.

                     

/gg|GroupGid:<Option>

The method to generate the GID for a group profile.

/gn|GroupName:<Option>

The method to generate the UNIX name for a group profile.

Option can be one of the following values. SamAccountName

is the default if this option is not specified.

                     

Methods:  

SamAccountName is the default if this option is not specified (for login, UID, GID).

Auto is the default if this option is not specified.

Auto            - Auto-generate from the AD group's SID.

RFC2307         - Group's AD RFC 2307 gidNumber attribute.

ZoneDefault     - The GID of this group in the default value zone for the target zone. Use the next GID of the target zone if the default value zone is not available.

SourceZone      - The GID of this group in the source zone.

(for classic zone only)

<Empty>         - Leave empty option for undefined GID.

(for hierarchical zone only)

                     

/v|Verbose           Verbose output messages.

/p|Preview           Preview only. No provisioning changes will be made.

/l|Log:<Level>       

Turn on the log file. The log file will be created in'C:\Documents and Settings\<CurrentUser>\Application Data\Centrify\Zone Provisioning Agent\Log'

Log level can be Error, Warning, Information or Verbose.

Example:

    zoneupdate /u:"Domain Users" /g:"Domain Users" /d:centrify.dev zone1 zone2