Friday, October 31, 2014

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:
  • It's a cloud-based Identity Provider
  • It provides access and SSO to on premise and cloud apps
  • Provides Mobile Device, Application and Container Management
  • It provides self-service capabilities (device enrollment, management, self-service password reset)
  • Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
  • Provides Multi-factor Authentication
  • Provides AD-based, Cloud-based or Mixed Identity
  • Works with Active Directory in a non-intrusive (no directory duplication) and secure way
  • Provides a policy engine for the directory
  • Provides Role-Based Access for Application access and Privilege Management
  • Provides multi-geography, shared or dedicated hosting
  • Provides an interface that
  • Provides access in rich (web) and mobile clients
  • Provides tenants with their own publicly-rooted certification authority
  • Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
  • Extensible by way of an SDK, customizations and branding.
  • Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
  • Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:
  • Deal with servers in the DMZ
  • Deal with understanding on premise federation technologies
  • Deal with understanding app authentication or federation patterns
  • Deal with publicly rooted certificates
  • Pay for expensive MDM solutions
  • Pay for 2-factor authentication solutions
  • Worry about geographically located solutions
  • Worry about language and branding
  • Worry about having a split strategy for mobile devices
This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:
  • What are the different Cloud IdPs and their pros and cons.
  • A policy for cloud-based access controls
  • A plan for service availability
We'll explore topics related to cloud in Security Corner.

User Suite Tour


Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (2/5)

This is the continuation of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-3Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.

CSC 12-5Ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.

CSC 12-8Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.

CSC 12-9 Configure operating systems so that passwords cannot be re-used within a timeframe of six months.

Why should you do this?
Because the password policy for admin accounts should be a step-up from regular users given that they hold the keys to the kingdom. 

What is the typical approach?
On Unix:  cracklib PAM module.
On Windows:  group policy.

What is the real challenge for organizations?
Human nature - sysadmins love their root or administrator accounts given their inherent mistrust in software, and unfortunately vendors promote fragmentation. 

Centrify's enhancers:
It's the solution that can accomplish this with true RBAC (allowing the administrative accounts to be put away) plus the tight AD integration with Group Policies (and support for fine-grained password policies).  In addition, Centrify's resiliency truly makes sure that the root or administrator account are only needed in emergency situations.


In UNIX - privilege elevation using Centrify-enhanced sudo (no sudoers) - DirectAuthorize (DZ)
In Windows - privilege elevation with the Centrify agent for Windows (DZ Win)


CSC 12-4Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.

Why should you do this?
Anyone that has had a Linksys router knows the answer to this.  In UNIX/Linux, there's too much reliance on the root account or the switch user command.  Local administrator in Windows is treasured by Windows admins.

What is the typical approach?
Unfortunately, in a lot of environments there's too much sharing of these accounts.  TACACs, RADIUS and password vaults help with network appliances.

What is the real challenge for organizations?
Human nature.  A Unified approach for these accounts like a password vault is typically the right solution.

Centrify's enhancers:
Due to the true RBAC and privilege elevation methods employed by Centrify, organizations can decrease their costs in password vault user licensing costs, by just leveraging it for non-human admin accounts, while the rest of the population uses RBAC.  The end-to-end nature and resilience mechanisms, makes it more efficient to align with regulatory requirements without a single point of failure.  In UNIX, single-user-mode or Windows safe mode without network will be the only instances in which these accounts are needed.

No need to check-out the keys to the kingdom each time the root, or administrator accounts are needed.
  • Tied to your identity infrastructure (Active Directory)
  • True Role-based access
  • Minimal process impact
  • Increased accountability using the native tools (syslog/event viewer)
  • Extensible to session capture and replay
Tried and true AAA.

CSC 12-6Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.

Why should you do this?
There was a time in the security discipline in which encryption was thought to be the solution;  time and different attack vectors have proven this to be wrong; however, encryption in transit and encryption at rest are a must.  There's an arms race going on because although algorithms are strong, Moore's law, virtualization and well-funded and motivated agents are lurking.

What is the typical approach?
Rely on the OS, Directory or the appliance.  Fortunately Microsoft has this very-well documented.

What is the real challenge for organizations?
Human nature, again  It doesn't matter how hard your encryption is if credentials are shared or clear-text passwords are used in scripts or other facilities.

Centrify's enhancers:
However, the bullets above are just marketing speak if we don't back-it up with examples:
  • Kerberized tools:  install.sh adjoin, adleave, adkeytab, adcert, dzdo + more are all Kerberized, which means no need to actually store passwords.  The Hadoop and MongoDB examples illustrate practical use.
  • Microsoft CA PKI client:  Use Certificates in your Unix, Linux, Mac systems.
  • Extend it to your HTTP, Java, SAP or DB2 needs.

Why even have the problem when you can completely avoid it?

Wednesday, October 29, 2014

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (1/5)

Background

One of our prospects looking at the Centrify privileged elevation tool for Windows, just highlighted to me that Server Suite is very well-aligned with the SANS Critical Security Controls Section 12: "Controlled use of Administrative Privileges" so I decided to take a deeper look.  We will cover 2 each post until we have the 14 topics explored.

Controlled use of Administrative Privileges


CSC 12-1Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.

Why should you do this?
Because the more somebody uses a privileged account the highest risk of malware being executed with elevation, more exposure to attacks like pass-the-hash attack, etc. 

What is the typical approach?
On Unix:  sudo, password vaults or RBAC
On Windows:  dash-a accounts, password vaults or RBAC

What is the real challenge for organizations?
Well, sudo is simple, proven but a pain, PVs just give out the keys to the kingdom in a controlled way - great for appliances BTW, and RBAC is hard to implement given that it typically requires multiple solutions.

Centrify to the Rescue:  Centrify Server Suite offers a serverless, cross-platform Unix, Linux and Windows based solution that provides access governance with RBAC leveraging AD.


End Result: The ability to limit access, control privileges (no giving out the keys to the kingdom) and reusing processes, cross platform, using existing technology and infrastructure.  This was explored in the 10-minutes PCI 7 challenge:.




CSC 12-2Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.

Why should you do this?
This is all about keeping track and being able to attest who approved the type of access that users have.  It's also an administrative preventative control.  This is not limited to domain accounts but local accounts as well

What is the typical approach?
The solution to this is basically workflow.  Unfortunately, simple workflow engines are hard to come by, or they are tied to a monster solution.  Scripts are popular as well.

What is the real challenge for organizations?
This should be relatively simple, but vendors don't make this easy.  Surprisingly PV vendors do a good job due to the appliance/proxy based nature of their solutions. Go to the vault, request access, approver gets notified, approves/denies, then the access is granted/denied.  Great for break/fix.

How Centrify helps?  Although Centrify does not provide workflow capabilities today (wink);  it makes it very easy for any IdM or workflow engine to perform the functions upstream.  Since the process boils down to AD groups and any decent workflow engine can do this, then the solution looks like this:


Utilities:  Automatic provisioning and role assignment is often achieved with ZPA.  This post and video cover a basic design:



In the next post we'll continue with the list.

Saturday, October 25, 2014

Labs: MongoDB-AD Integration with Centrify - The Kerberos Remix

Background

In the previous post, we discussed how with Centrify, MongoDB authentication can be streamlined and we discussed SASL Auth integration.  We also discussed how to leverage the authorization capabilities of Centrify to limit access to MongoDB via PAM with SASL.

However, SASL is a simple option and can be greatly enhanced by using a different option.

Advantages of using AD Kerberos with Centrify

Centrify automatically creates and maintains the Kerberos environment of a UNIX, Linux or Mac OS X environment, no need to deal with /etc/krb5.conf files, machine keytabs or incompatibilities because Centrify's shared objects are optimized to work with AD regardless of the complexity of the AD environment (one-way trusts, cross-forest trusts, etc).

The key benefit here is time to production.  When App Developers or DBAs don't have to worry about standing up an environment (such an MIT Kerberos realm), maintaining and understanding Kerberos, it's easier to focus on the tasks around MongoDB.  Active Directory is your Kerberos infrastructure and Centrify is the enabler.

From a business perspective consistency is preserved by eliminating duplication of capabilities and processes.
From a security perspective, the access model remains the same and no additional attestation mechanisms need to be created.
From the user's perspective they are more productive because we can eliminate an additional authentication prompt (remember how bad it looked when we saw the plaintext passwords on the screen?)

Another benefit is the utilities like adkeytab that allow for the provisioning and maintenance of service accounts and kerberos key tables in your systems.  MongoDB uses the GSSAPI interfaces to provide Kerberos authentication.

Moderation note:  This post requires that you understand the basics of Active Directory and Kerberos.  If any of these terms: domain controller, kdc, service principal name, user principal name, TGT, TGS, DNS, etc, are foreign to you, please do some background study.

Basics:  What is GSSAPI?

Wikipedia:  "The Generic Security Service Application Program Interface (GSSAPI, also GSS-API) is an application programming interface for programs to access security services.."

The key here is that MongoDB supports Kerberos via the GSSAPI interfaces, Since Centrify makes Kerberos work effortlessly , the implementation is relatively simple:



MongoDB will start with GSSAPI authentication enabled and will use the key table file (keytab file) of an AD service account that has a UPN set to mongodb/<fqdn of system>@DOMAIN and an SPN set to mongodb/<fqdn of system>.  This will allow for it to request a ticket-granting-ticket or a service ticket depending on the call.

Implementation  (on CentOS)

Note:  You will need the Enterprise Edition of MongoDB to get this going.  For instructions of how to set up, go here: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos   (use CentOS to follow along) - I will be elevating with dzdo:

Use adkeytab to create the service account and key table file for MongoDB

Adkeytab has been discussed previously here.  Remember that when you use it, the service account's password is randomized;  this eliminates the risk of several people knowing the credentials of a shared account, however, makes the burden around protecting the keytab file.  Make sure you have protocols around this.  If you're using separation of duties, the UNIX admin may not have the rights to create a service account in AD, so you have to work in cooperation with the AD team.
Note:  Remember that the Centrify Kerberos tools are in the /usr/share/centrifydc/kerberos/bin directory.

Step 1:  Understand the adkeytab parameters:

  • this is a new account  (the -n option is required)
  • credentials are required to create the new account (-u <ad user that can create>)
    e.g. jerry.seinfeld  (the AD admin in my environment)
  • a key table file will be created (-K /path/to/file)
    e.g. /etc/mongodb.keytab
  • An OU for service accounts in AD will be used (-c "dn of ou")
    e.g. "ou=Service Accounts"
  • A UPN will be specified (-U service/principal@REALM)
    e.g. mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
  • A SPN will be specified (-P service/principal)
    e.g. mongodb/cen3.corp.contoso.com
  • The UserName (samAccountName) will be different than the cn (-S name)
    e.g. mongodb.service  (note:  the limit here is 20 chars)
  • The final parameter is the cn
    e.g. mongodb
Step 2:  Run adkeytab in verbose mode  (elevated to be able to copy on /etc)

$ dzdo adkeytab -V -n -u jerry.seinfeld -K /etc/mongodb.keytab -U mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM -P mongodb/cen3.corp.contoso.com -c ou="Service Accounts" -S mongodb   mongodb

ADKeyTab version: CentrifyDC 5.2.0-218
Options
-------
use machine ccache: no
domain: corp.contoso.com
server: null
gc: null
user: jerry.seinfeld
container: ou=Service Accounts
account: mongodb
trust: no
des: no
jerry.seinfeld@CORP.CONTOSO.COM's password:
Attempting bind to corp.contoso.com site:CorpHQ server:dc1.corp.contoso.com: ccache:MEMORY:0x5666c0
Bind successful to server dc1.corp.contoso.com
Attempting bind to GC domain:corp.contoso.com site:CorpHQ gcserver:dc1.corp.contoso.com ccache:MEMORY:0x5666c0
Bound to GC server:dc1.corp.contoso.com domain:CORP.CONTOSO.COM
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
Searching for AD Object: filter = (samAccountName=mongodb.service$), root = DC=corp,DC=contoso,DC=com
AD Object not found.
Building Container DN from OU=SERVICE ACCOUNTS
Account 'CN=mongodb,OU=SERVICE ACCOUNTS,DC=corp,DC=contoso,DC=com' does not exist
Search for account in GC: filter = (samAccountName=mongodb.service), root = DC=CORP,DC=CONTOSO,DC=COM
SAM name 'mongodb.service' not found in GC
Problem to create account; try again with no password required
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 1
Adding managed account keys to configuration file: mongodb
Changing account 'mongodb' password with user 'jerry.seinfeld@CORP.CONTOSO.COM' credentials.
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 2
Success: New Account: mongodb

Step 2:  Verify the AD user account attributes and make sure you can get a TGT and a TGS with the keytab  (elevating to read from /etc)

$ adquery user -PS mongodb
userPrincipalName:mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
serverPrincipalName:mongodb/cen3.corp.contoso.com
Principals are OK.
$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
[cosmo.kramer@cen3 ~]
$ dzdo /usr/share/centrifydc/kerberos/bin/klist                                                               Ticket cache: FILE:/tmp/krb5cc_1149240408
Default principal: mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 14:19:40  10/26/14 00:19:40  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
        renew until 10/26/14 14:19:40
TGT successful.
$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab -S mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM mongodb

$ dzdo /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1149240408
Default principal: mongodb@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 14:20:00  10/26/14 00:20:00  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
        renew until 10/26/14 14:20:00

TGS successful

Step 3: Secure the Keytab

Copy the keytab to /var/lib/mongo
$ dzdo mv /etc/mongodb.keytab /var/lib/mongo/mongodb.keytab 
Change the owner of the keytab to mongod
$ dzdo chown mongod:mongod /var/lib/mongo/mongodb.keytab 


Set up a test user and configure MongoDB for GSSAPI authentication

Note:  If you don't know how to properly set up users in Mongo and you're following along from the SASL posting, just disable auth and create the user.  We will reenable it later.

Step 4:  Make sure that SASL is configured to work with PAM and identify the path for the socket.
$ mongo
> use $external
switched to db $external
> db.createUser({user: "j.peterman@CORP.CONTOSO.COM",roles: [ { role: "read", db: "reporting" }]})
Successfully added user: {
        "user" : "j.peterman@CORP.CONTOSO.COM",
        "roles" : [
                {
                        "role" : "read",
                        "db" : "reporting"
                }
        ]
}

The result should be success.  Keep in mind that the user's domain has to be in CAPS.


Step 5:  Set the KRB5_KTNAME environment variable for the keytab
vi /etc/sysconfig/mongod
and add this line:
export KRB5_KTNAME=/var/lib/mongo/mongodb.keytab

Step 6:  Edit the mongodb.conf file to enable GSSAPI
Comment out the bind_ip directive. For Kerberos SSO to work, you must bind over the network.
Otherwise the appropriate will be localhost versus the actual hostname of the system

#bind_ip=127.0.0.1

Re-enable authentication.  Note that you can enable both SASL and GSSAPI
auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux

setParameter=authenticationMechanisms=PLAIN,MONGODB-CR,GSSAPI

Restart MongoDB and make sure there are no errors.
$ dzdo service mongod restart

Test GSSAPI/Kerberos authentication

Step 7:  Log in to the system with the externally identified user that was created with the full UPN, inspect the Kerberos TGT.

$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1149240919
Default principal: j.peterman@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 15:23:35  10/26/14 01:23:35  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35
10/25/14 15:25:13  10/26/14 01:23:35  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35

Notice that during login, Centrify will automatically kinit and enable your TGT.

Step 7:  Launch mongo with the system name and perform the testing.

mongo cen3.corp.contoso.com
MongoDB shell version: 2.6.5
> db.getSiblingDB("$external").auth({mechanism: "GSSAPI",user:'j.peterman@CORP.CONTOSO.COM',})
1

Output of 1 proves that authentication with Kerberos/GSSAPI was succesful.

> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'j.peterman',pwd:'<jp's password>',digestPassword: false})
1

Both GSSAPI and SASL Plain can be used simultaneously.  Kerberos is superior due to the fact that the user eliminates one prompt ad a readable password.

Video

Friday, October 24, 2014

Business Problems: Using MongoDB with AD leveraging Centrify

About MongoDB

MongoDB is becoming increasingly popular alternative to other database offerings.  What's really refreshing about it is that unlike some other established database leaders (Ahem.... big O) they do provide several mechanisms for authentication.  This means flexibility!

As of this writing, MongoDB offers the following authentication mechanisms:
Reference: http://docs.mongodb.org/manual/tutorial/enable-authentication/
  • X.509 certificates
  • LDAP with AD or OpenLDAP leveraging SASL
  • Kerberos

What's the business problem here?

Typically the folks dealing with apps and databases are not experts on authentication.  This means cognitive, cooperation and coordination issues and obviously time-to-production challenges.
In addition, if your Linux/UNIX infrastructure does not implement a robust set of access control technologies, each additional node adds to the problem.

This post covers
  • SASL (plain) integration leveraging PAM
  • Limiting Access using Centrify Access components

How Centrify can accelerate and secure MongoDB deployments?

  • By providing THE most robust and thoroughly tested way of integrating non-Windows platforms (Unix/Linux/OS X) to Active Directory.
    • No need to worry about setting up multiple LDAP servers (Centrify is sites and services aware)
    • In the SASL use case, no need to worry about plaintext communications since ultimately Centrify uses Kerberos.
    • In the GSSAPI/Kerberos, Centrify maintains the environment for you and provides tools for ease of management.
  • Faster results - time to market these capabilities
  • Enhancing security by implementing privileged user management.

Basics:  What is SASL?

As per Wikipedia:  "Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL."


The key here is that MongoDB supports SASL and SASL can use PAM.  Since Centrify makes PAM work with AD out of the Box, implementation is very simple:


Implementation  (on CentOS)

Note:  You will need the Enterprise Edition of MongoDB to get this going.  For instructions of how to set up, go here: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos   (use CentOS to follow along) - I will be elevating with dzdo:

Test and Configure SASLAUTHD

Step 1:  Make SASL(saslauthd)  is in your system and working and they cyrus-sasl-plain is installed
$ cat /etc/redhat-release
CentOS release 6.5 (Final)
$  adinfo -v
adinfo (CentrifyDC 5.2.0-218)
$ service saslauthd status
saslauthd is stopped
$  rpm -qa | grep cyrus-sasl-plain
cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64

Notes:
If the cyrus-sasl-plain package is not present, use yum or other utilities to add it.
The saslauthd is stopped, this means that the service is not set to start automatically.

Step 2:  Make sure that SASL is configured to work with PAM and identify the path for the socket.
$ cat /etc/sysconfig/saslauthd | grep MECH
MECH=pam
# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
$ cat /etc/sysconfig/saslauthd | grep SOCKETDIR
SOCKETDIR=/var/run/saslauthd


Step 3: Test SASL by determining your valid AD users and testing interactively
# to determine who can log in to your computer from AD
$ adquery user
cosmo.kramer:x:1149240408:1149240408:Cosmo Kramer:/home/cosmo.kramer:/bin/bash
george:x:1149240406:1149240406:George Constanza:/home/george:/bin/bash

Step 4: To start saslauthd interactively  (with PAM support and verbose)
$ dzdo saslauthd -a pam -d
saslauthd[4022] :main            : num_procs  : 5
saslauthd[4022] :main            : mech_option: NULL
saslauthd[4022] :main            : run_path   : /var/run/saslauthd
saslauthd[4022] :main            : auth_mech  : pam
saslauthd[4022] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
<...>

Step 5: In another terminal or SSH session, test SASL with PAM using testsaslauthd

$ testsaslauthd -u cosmo.kramer -p <kramer's password> -s login -f /var/run/saslauthd/mux
0: OK "Success."

This means that SASL with PAM is working as expected.

Step 6: Now you can make SASL start automatically if needed
$ dzdo chkconfig saslauthd on

$ chkconfig  | grep saslauthd
saslauthd       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Create a PAM configuration file for mongod
Step 7: Because we've configured SASL to use PAM, now we need a configuration file that has the system or centrify entries.  In my example, I'm piggybacking on the sshd config since I already know it works with AD users.  We also want to make sure that the "other" PAM config file is leveraging the Centrify PAM modules as well

$ cp /etc/pam.d/sshd /etc/pam.d/mongod
$ cp /etc/pam.d/sshd /etc/pam.d/other

Ultimately, for both auth, account, password and session, these files include password-auth (in CentOS), which basically has the Centrify PAM directives - here's an excerpt of password-auth:

cat /etc/pam.d/password-auth
# lines inserted by Centrify Direct Control (CentrifyDC 5.2.0-218)
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

This is what makes the magic happen.  The video below covers steps 1 thru 7.


Configure MongoDB

Step 8: Configure MongoDB Security for SASL and restart it.

Set the following parameters in the /etc/mongodb.conf file:
auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux
setParameter=authenticationMechanisms=PLAIN,MONGODB-CR

Auth has to be set to true and the parameter saslauthdPath has to be set to the socket in /var/run/saslauthd/mux  - Make sure the folder and file have the correct permissions.  Finally, the authenticationMechanisms havs to include Plain (for SASL).

To restart MongoDB with service, use:

$ service mongod restart

Test SASL/PAM authentication with MongoDB

To test, you'll need an externally identified user.  We will use the same user we used to test SASL

Step 9:  Create an externally identified user in MongoDB

$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("admin")
admin
> use $external
switched to db $external
> db.createUser({user:"cosmo.kramer",
roles:[{role:"read",db:"reporting"}]})

The output should be:

Successfully added user: {
        "user" : "cosmo.kramer",
        "roles" : [
                {
                        "role" : "read",
                        "db" : "reporting"
                }
        ]
}

Step 10: Test SASL authentication inside MongoDB

$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'cosmo.kramer',pwd:'<kramer's password>',digestPassword: false})

The output should be:

1

The output of 1 means Success.  This is a very simple process for using the PLAIN method, but what's the issue here?  The password is in plaintext, even in our testing it was visible.  We will improve on this by using Kerberos, but first, let's add some access controls by leveraging the authorization components of Centrify.

The video below covers steps 8-10




Limiting access to MongoDB using PAM granular access controls leveraging Centrify

You may want to add an additional layer of security, for example, in a shared system, you may want to grant a super-set of users access to the box, but limit who can log in to MongoDB via SASL with PAM.  For this, you have the ability to create a role with the PAM mongod access right.

Step 10:  Create the MongoDB PAM Access right

  1. In Access Manager, navigate to Zone > Authorization > UNIX Rights Definitions > PAM Access
  2. Right Click and Select Add PAM Right, and set it up like this:
    Name: MongoDB
    Application: mongodb

At this point, if you have any role with the MongoDB database profile, you can add this PAM access right to make sure that they have access to MongoDB;  other users with just the ssh right, will be able to log into the box, but won't be able to log into MongoDB.

The video below showcases how to leverage PAM Access rights as an additional security layer for MongoDB with Centrify:

Tuesday, October 7, 2014

Basics: Federation IS NOT Authentication

Commentary

Technology goes at a fast pace, unfortunately for IT professionals we are too busy at work to sit down and sharpen their skills.  Understanding the basics and frameworks about technology really can make a difference, however, I'm increasingly frustrated because I notice that even at architecture-level conversations I notice major knowledge like, knowledge of the problem, requirements, framing the conversation around security, understanding the basic standards and protocols.
How are you supposed to make technology decisions for organizations when you don't understand the basics?

Back in the day when I was a systems administrator,  I remember studying the inner works of Microsoft Exchange.  The framework was very basic, a client-server model that included
  • Storage Providers
  • Address Book Providers
  • Messaging Transport Providers
This meant that when somebody was pitching to me a Fax solution that integrated with Exchange, I knew the key questions:  
  • For usability - how does the fax addressing system integrates with the GAL
  • For implementation - are there any client components?
  • For troubleshooting - how do faxes get routed?
Another example in networking is the OSI and TCP/IP models.  I remember the good old Cisco Book by Oppenheimer "Internetworking Technologies Handbook" (I still recommend it) - basic things like in which layers flow control is important (layer 2) gave any IT professional a framework of what capabilities corresponded to each protocol.

This post is about the differences between Authentication and Federation.  Unfortunately when talking to folks that are looking at User Suite it's quite common for them to intermingle these terms.

What is Authentication?

Authentication is the process of verifying that a subject or program is who they say they are.  Notice the sequence here.  The's an assertion (who you say you are) and what are called "factors":

- Who you say you are  (username or unique identifier) - this is constant.
- Something you know (a password or paraphrase)
- Something you have (a physical token, smartcard, or one-time-password mechanism)
- Something you are (the patterns in your fingerprints, retina or voice)

Authentication happens directly.  There's a directory (like AD) that has a database of users and unique identifiers (UPN or sAMAccountName in AD), a password verification and protocol for authentication (Kerberos).   It happens every day, when you press Ctrl+Alt+Delete and type your password, when you access a file-share and silently get authenticated via Kerberos.  Strong authentication can be enforced by combining factors:  E.g. Something you know (password) + Something you have (hardware/software one-time token).

It happens when you go to Amazon, Facebook or when you do online banking.

What about Federation?

You've all seen the acronyms:  IdP, RP, SAML, Assertion, XML, etc.   What does it mean?
The best way to explain federation is to use an example.  

Let's introduce Joe Smith, he has a plane a reservation to Sidney Australia via Oceanic Airlines  (I wouldn't recommend that airline given the events in LOST), the sequence is typically as follows:
  1. Joe Smith arrives at the airport and goes to the Oceanic ticket counter
  2. He makes the following claim or assertion:  My name is Joe Smith and I have a reservation to Sidney, hands over a printout with this assertion, it includes a seat number and class.
    Let's think about this.  The ticket clerk does not hand Joe his boarding pass because the level of assurance that the information is accurate is very low. After all, somebody may be trying to impersonate Joe or he may not even have a reservation.  What if he arrived late or in the wrong date (this is known to happen).
  3. The ticketing clerk confirms part of the assertion - Joe Does have a reservation, not only that, he is entitled to a premium seat 42B.
  4. At this point, the clerk decides to confirm the other part of the assertion:  Joe's identity.  She asks, "can you please provide me with your passport?"  - because this is an international flight, the clerk verifies the Photo, Name/Last Name, DOB and Passport expiration date.  These fields have to match the system;  she checks Joe's face again, and proceeds to issue a boarding pass.
    Now, let's think about what happened here.  
    • The airline can't confirm directly that Joe is who he says he is.  
    • The airline relies on the US government's Passport Office's process and that they did their due-diligence in making sure they issued the passport to the correct person.  This makes the USPO the Identity Provider and the airline is the Relying Party. The airline has a trust relationship with the USPO.
    • This means that the process in the USPO performs the authentication that Joe is who he said he was prior to issuing the document.
    • The ticket also includes an entitlement.  Joe is entitled to seat 42B in the economy section.
This is Joe Smith's Boarding Pass.  Once his identity is verified, he'll be issued one.
Now we can look at the way Identity Federation is implemented in the the context of SaaS applications:

SaaS applications and many on premise applications can authenticate users directly OR support federation via a popular protocols like SAML.  This means that they can be a relying party.  When configuring an application for Federation, you'll be asked about the building blocks like:
  • Certificate:  This is a key building block for a federation agreement or trust relationship.  The identity provider and the relying party establish the agreement by using a publicly rooted certificate.  If this certificate expires, the federation trust is broken.
  • Assertion or claim details:  how is it going to be composed?  It could be as simple as a username or email address, or as complex as email, role, purchasing level, etc.  It's all based on the app.  In addition, a schema (XML) that provides the definition of assertions may need tob e provided.
  • Redirection URLs:  Where to forward the encrypted claim or assertion;  This could be login, logout or error.  These typically are the Identity Provider's URLs to process the assertions and handle session or error management.
  • Provisioning options:  Some apps support provisioning models like SCIM. More on this on a later posting.
It's important to understand that many SaaS apps allow mixed scenarios in which they can authenticate locally or using Federation at the same time.

How it works - just like the airport scenario, but online.
  1. The subject or user attempts to access the application by providing an assertion (e.g. email address or username, e.g. joe.smith@corp.contoso.com)
  2. The application (relying party) looks at its internal rules and sees the federation rules for that user.  Assuming SAML.
  3. The assertion is encrypted and forwarded to the login URL to be processed by the Identity Provider.
  4. The identity provider performs its internal checks (is the user active, allowed to access the app, etc - all based on the assertion)
  5. The identity provider returns the verification result and any additional information required.
  6. The subject is granted or denied access to the application and maybe depending on the application, information about entitlements may also be provided.
Here's the mapping of the Add Application Wizard for Centrify to enable SAML Federation for Salesforce:

Centrify User Suite - Application Wizard for Salesforce - it takes literally minutes to set up.
Centrify User Suite leverages Active Directory on the customer's premises to perform the validation or authentication, this means that the enterprise keeps control of key directory attributes and password data.

Recommended Reading

A Guide to Claims-Based Identity and Access Control, Second Edition

Although Microsoft-centric, the book does a great job and uses very good examples.  It's a free download (see link) or you can always get the hardcopy.

Monday, October 6, 2014

Basics: What constitutes a cloud identity?

Hola!! from Panama City.  At Centrifying we are tasked to represent Centrify in the ISACA Latin America CACS 2014.
We had a chance to educate the attendees in the challenges and concepts of cloud identity and SaaS access controls security.

Background

This new series focuses on Identity as a Service (IdaaS).  As you probably know by now, Centrify has two product lines Server Suite and User Suite.  The first basic topic is to understand what constitutes a cloud identity.  At a basic level, the identity that supports a SaaS application can be as simple as a unique identifier and a password; However, that doesn't translate into a very valuable app.

So what's the problem with SaaS apps as it relates to Identity?

Since SaaS apps extend the IT boundaries beyond the on premises data center over the Internet the most basic issues are around timely provisioning.  Once a user leaves the company if the offboarding process is not timely and efficient, the organization is exposed to a potential data loss.  Unfortunately, just like the issue with the  heterogeneous datacenter, the solution sets today promote capability and process fragmentation and here's where Centrify can help.  Furthermore, let's explore the problem by at further length.

The typical cloud IdaaS providers may make you think that the issue is just Cloud Identity and SSO (federation), but the problem goes beyond that.  Let's explore some aspects:
  • License assignment:  this topic impacts the bottom-line.  How does your process makes sure that the user is properly licensed (no more than what they need), and that licences are administered accordingly.  
    Timely license management has cost implications
  • Role, Profile or Group management:  Depending on the application, entitlements determine what the user can do within the application. This is key for sound security.
     
    Salesforce provides access to different functions based on the user's profile
  • Multi-factor Authentication (MFA) and 2-Step-verification:  These capabilities are increasingly a must because they are the foundation for different types of policies.  The recent consumer services data-breaches illustrate that need.
    MFA and 2-step verification are a must nowadays, the issue is - how to standardize.
  • Policies:  Each SaaS provider has a different way to deal with policies.  Would it be nice to do it in a single management framework? and wouldn't it be nice if it's enforceable across all endpoints including mobile devices?
    Different SaaS providers provide different policy frameworks
  • Support for Mobile Device Management (MDM) Mobile Application Management (MAM) and Mobile SSO:  This capability is also a must;  as phones and tablets become more powerful, mobile computing is a big tool in the information worker arsenal.
    MDM has become commoditized, MCM is looking for a standard, but MAM and Mobile SSO are growing

Is there a Unified Solution out there that is friendly to Active Directory?

So the question is - What if there's a solution out there that allows you to use an existing infrastructure (AD) to solve all these issues without the need of additional infrastructure or the need of complex Identity synchronization?   

YES!

That is what Centrify User Suite is all about! The next posts will focus on the service and 3 apps: Google Apps, Office 365 and Salesforce.  The first post will explore what Federation is and isn't.  Look for the Cloud-labeled articles.

Thursday, October 2, 2014

Why the Directory Services battle resembles a Groundhog Day

Groundhog day - Columbia Pictures

Another release, another day....

Many of us have seen or heard about the movie, in Groundhog Day, Phil Connors (played by Bill Murray) gets stuck in a loop in the same day (Groundhog day) in small town in Pennsylvania, only to break it when he changes from an arrogant to a humble individual.

In this opinion post, I examine the similarities between the strategies of many software provides in the context of Directory Services and I will use a very recent example to illustrate such point.  As long as we continue in the groundhog loop, organizations are subject to capability duplication and operational inefficiency.

But first, a quick primer.

Background

We are not going to go back into prehistoric times, let's just talk about the 80s and up.  I have observed 3 design philosophies when it comes to directory services:
  1. A Directory service is just a directory, it should be fast, lightweight and efficient.  The best example of this is Netscape Directory.  Others worth mention, OpenLDAP, ADLDS, etc.  The biggest triumph of these type of directories is that they enabled the development of the internet that we know today.
  2. A Directory service should contain complementary services and specialized clients:  Novell NDS, NTDS, eDirectory and Active Directory are good examples.  They come from vendors that had a stake on Enterprise Networks.
  3. A Directory should be an end-all/be-all tool for consolidation (a Meta Directory) because the modern enterprise (partners and subsidiaries) are complex, therefore these requirements must be satisfied.  

The Pitfalls

Let's examine the common themes:

Groundhog bullet #1:  The just-a-directory approach does not meet the needs of an Enterprise - promotes IT fragmentation.

This is because ultimately a directory service needs an authentication and a policy enforcement mechanism.  So we eliminate philosophy # 1 because it suits internet directories, not enterprises.  The key approach here is OpenLDAP as an Enterprise Directory.  You have to couple it with Kerberos, NTP and some sort of policy engine to make it work in a Unix, Linux or Mac Environment.  So it is not a complete vision.  It also unfortunately requires that the data is synchronized from or to another directory.

Groundhog bullet #2:  Meta-directories are a necessary evil that is too commonly positioned

Anyone that has been involved in a sizable Identity Management project understands the need for a meta-directory.  Not all identity sources (directories) are authoritative for all objects and attributes.  The authoritative source for Employees is the HR System (e.g. PeopleSoft), for business extensions may be your PBX, for email it's  your enterprise messaging system; sub-organizations may be isolated. Meta-directories are the perfect solution for these types of problems, HOWEVER, they are often positioned incorrectly.  Great for the software vendor's consulting arm, but painful for customers.  Pain = too much money + too many resources + too much organizational impact.

Groundhog bullet #3:  Lack of Windows Client

NDS led NTDS and Active Directory in its initial roll-out for a reason they had an excellent client that worked on windows.  Any true Directory contender will have multi-plattform strategy that includes Windows.  Although many software providers don't want to work with Microsoft, but the Authentication Provider APIs (formerly known as GINA) are widely available and documented.  

Novell has been successful by having a multi-platform strategy that includes Windows.

An Example:  FreeIPA and SSSD

With the backing for RedHat, the FreeIPA project started with the right idea.  Let's become Active Directory, but for Linux.  And everything looks great so far:
  • An LDAP server (389 Directory Server)
  • An integrated Authentication Service (MIT Kerberos) and NTP for time sync
  • Integrated DNS 
  • Integrated Certificate Authority (Dogtag)
Looks a lot like the comparison I made in this post.  Here are some of my observations:
  • FreeIPA overcomes the issue of IT fragmentation by providing an integrated package.  The current roadmap offers good hopes for Enterprises.
  • Unfortunately, and probably due to the link to RedHat, FreeIPA's priorities are around Linux at this point, but hopefully they will include a Windows client.  
  • Interestingly, and mostly due to avoid a Windows CAL use is a noble goal but the whole thing about implementing an additional directory will be a challenging proposition in any mature environment (maybe in a brand-new RHEL-derivative environment)?
    The CAL usage is not an issue in Enterprise environments.  See my comments about this topic below.
  • Finally, the most interesting part is the client (SSSD), it's an improvement over Samba/Winbind or LDAP/Kerberos.
I love what FreeIPA means to competition and customers.  It forces the big players (Microsoft, Novell/NetIQ, etc) to stay on their toes and provide value.  What I don't like is the recommended deployment method summarized in this slide:


The meaning to any prospect looking at native AD integration with RedHat is that beyond 30 clients  a new infrastructure is required (IPA) with a Kerberos trust with Active Directory.

What about operational efficiency?  

At Centrify the "Unified Identity Infrastructure" theme is all over the place and on purpose, with no duplication of capabilities, the security and operational benefits can be obtained faster and the cost of compliance goes down.  What is an IT Manager going to say when they hear that they need yet another infrastructure to manage?

This is why at Centrify we always welcome competition during evaluations, it showcases the sad truth that "the devil is in the details" and at the end of the day, the more mature and easier to use solution that does not require additional infrastructure prevails.

I admire RedHat, they are good for the IT infrastructure industry because they provided an alternative to the expensive UNIX distributions, but in this context (AD Integration), instead of focusing on creating a true Active Directory client, they are optimizing SSSD to be a great FreeIPA client.  I also understand them, they don't have an incentive to strengthen Microsoft's position in the Enterprise, but what I don't agree on is when a RedHat salesperson says "With FreeIPA/SSSD you don't need Centrify" that is just simply not accurate and unfair to customers and prospects.

It's early in their strategy and I'm of the opinion that they can continue to develop SSSD's AD integration capabilities while developing a Windows client for FreeIPA;  this will position FreeIPA in a better position against AD and eDirectory; Who knows?  In time a Centrify agent for  FreeIPA can be viable based on market share and penetration.

I will continue to explore the new capabilities of FreeIPA/SSSD and we'll discuss what's new and what's improved in a later post.