Basics: Kerberos Super-Simplified

Cerberus the 3-headed dog

Kerberos is a protocol that leverages DNS, cryptography, a distributed client-server model, clients and time synchronization and ticket exchanges to provide secure authentication.

From a Security perspective, Kerberos resolves the following:

• Enforces confidentiality because it makes sure that passwords are not in the clear over the network.
• Protects integrity of the transaction by making sure that exchanges are not tampered with during transit
• Provides high-availability (if properly implemented) by allowing for it to be deployed in a distributed fashion

For Kerberos to work,

1. DNS name resolution needs to be working correctly
2. There has to be a Directory Service to store service principal names (like LDAP) and service principals need to be registered in the proper attributes of the directory
3. The Key Distribution Server needs to be available
4.  Time between clients and servers can't be skewed more than 5 minutes (time servers have to be implemented)
5. Client software needs to support Kerberos and the Kerberos environment has to be properly configured.

Active Directory can solve all these issues.  As a matter of fact, any Working windows network today (that has Windows 2000 and up) has a working Kerberos environment.  Kerberos is used by millions of people every day:

a) Bob signs into his Windows computer in the morning.
b) As he signs in successfully, a Ticket Granting Ticket (TGT) is issued for him with a duration of 10 hours.
c) When he opens his email (Outlook) and is able to start work on pending tasks.

Note: In a normal configuration he does not need to type-in his password again to open the program; because the "Kerberized client" (Outlook), the "Kerberized Server" (Microsoft Exchange), the Directory, Key Distribution Server, Policy Server and DNS server (the AD Domain Controller) take care of the rest.

Notice all the functions performed by Active Directory

Function	Provider
Provides name resolution	AD Domain Controller – DNS Service
Issues, validates tickets	AD Domain Controller - KDC
Provides encryption services	AD Domain Controller  - AES 256
Defines and enforces Kerberos policies	AD Domain Controller - Group Policy Engine
Directory Services	AD Domain Controller - LDAP
Provides time synchronization	AD Domain Controller - win32 time service
Provides high-availability and standard configuration	AD Domain Controller - replication
Kerberized Client	Windows 7, Microsoft Outlook
Kerberized Server	Microsoft Exchange

Notice the fragmentation on UNIX/Linux

Function	Provider
Provides name resolution	BIND
Issues, validates tickets	Kerberos KDCs (MIT or Heimdal)
Provides encryption services	LDAP (SSL or TLS) Kerberos (for auth only)
Defines and enforces Kerberos policies	Configuration files
Directory Services	OpenLDAP  (& other packages)
Provides time synchronization	Network Time Service (NTP)
Provides high-availability	Multiple solutions: -          LDAP Sync (for OpenLDAP) -     BIND master/slaves -          Kerberos Master/Slaves -          Filers and export shares for configuration files
Kerberized Client	Many available, but not all support Kerberos This is not important in the context of this conversation
Kerberized Server	Many available, but not all support Kerberos. This is not important in the context of this conversation

Notice the variety of products, and now think:  What's in a capability?

People-Process-Technology

This example illustrates a phenomenon that plagues many organizations today:  IT Fragmentation.  For each of these solutions organizations require specialists (people), deviations in how things are done (process) and as you can see above, different solutions (Technology)

This is why, in my previous post, the IT manager is concerned about costs and organization agility.

Service Principal Names
SPNs are the "names" associated with a service.  The service (like a web server, host, file server, etc) executes in that security context.  Better definition here.

The syntax is: < service type >/< host name >:< port number >

In a practical sense, the meaning is this, if a service (let's say Apache, or httpd) wants to use Kerberos authentication, not only it has to be Kerberized, but the host of the service has to have an SPN for that service in the Directory service.  For example, for the host web.contoso.com, the http running on port TCP 8080 service's SPN is:  http/web.contoso.com:8080

Not specifying a port, basically assumes the default port.  In our example, port TCP 80.

Troubleshooting Kerberos

Troubleshooting Kerberos takes a lot of practice and will be revisited later, but here are a basic set of steps.  Just ask yourself:

1. Is the service Kerberized?
2. Is name resolution working?  Can DNS resolve by FQDN or short name?
3. Is the time synchronized between the client, server and KDC (DC in AD)
4. Are the correct SPNs registered  (remember that you can do short names and FQDNs)?
5. Finally, the fact that you can authenticate, does not mean that you're authorized!!!

Unix/Linux Access Controls: A tale of four audiences

UNIX and Linux Administrator I am worried about not being able to log-in to do my job if Active Directory is not available I am concerned that the integration with AD will be very intrusive to my Unix and Linux systems I am concerned that the privilege management model won't allow me to do things as root when I require it. I am concerned that I won't be able to leverage scripting and automation I'm spending a lot of time to produce information for security attestation I'm concerned that each time I need to do something I will need to go to the Windows guys for permission. Do I need to go changing file ownerships (chown) once this is implemented?

Active Directory Administrator I'm concerned that this solution will require to extend the AD schema I'm concerned that I will need to run services in Domain Controllers I'm concerned that the agent will eat my DCs CPU and Memory with multiple persistent LDAP connections  I'm concerned that now I will have more work since I have to help the Unix group.

Security Analyst I need to make sure only the right people can access the Unix and Linux Systems (least access principle) I also need to make sure that shared accounts (like root) are only used when required I need to make sure accountability is increased I need to make sure people can only have the privileges that they need (least privilege principle) I need to satisfy audit reports and close open audit comments We need to align with Regulations (SOx, HIPAA, PCI, etc) I am not sure that we can really pin-point who did what at a certain point (bad change control, data-breach, etc)

IT Manager or IT Architect I am concerned that we're spending a lot of money in point solutions I'm concerned that the project will not yield results on time I'm concerned that processes like password resets, provisioning, de-provisioning, and attestation are very complex. I'm concerned that any new solution is going to require a ridiculous amount of infrastructure. I'm concerned that even though we have top of the line solutions, it seems it takes a long time to get stuff done.

Basic Concepts: The Centrify Agent

Centrify's Active Directory Client
Typically known as DirectControl (or adclient) is Centrify's Active Directory integration service.  It leverages AD LDAP, Kerberos and Group Policy;  with over 10 years of maturity, the agent has evolved to support diverse platforms and has provides super user privilege management for UNIX/Linux and Windows platforms.

 

 The architecture of the client in UNIX is as follows:

• NSS Module:  Uses the NSS facility to present AD as a source of of identity for users (passwd), and groups.
• PAM Module:  The authentication against AD is implemented as a PAM module.  Centrify implements authentication, account, session and password modules.
• Kerberos Libraries:  MIT Kerberos compiled libraries with support for Microsoft's Kerberos implementation.  The location of these tools is /usr/share/centrifydc/kerberos/bin.
• Group Policy Engine:  Processes group policies from AD in the Unix/Linux and Mac platforms
• Centrify-enhanced sudo:  A version of sudo that leverages Roles and Rights defined in AD with Centrify.
• Command-line Tools:  Centrify has implemented command for the agent (ad commands), for privilege management (dz commands) and for auditing (da commands). In addition, there are modules for PowerShell for the DirectManage components, as well as an SDK.
• LDAP and NIS Proxies:  These proxies present AD information to clients that can't have the agent installed (like filers, appliances, or legacy systems)
• Offline credential cache:  Provides high-performance (by not requiring a persistent LDAP connections to AD) and high-availability (in case AD is not available or there's a network failure)
• External Modules:  provides SSO facilities for Apache, Tomcat, Websphere, Weblogic Java2EE application servers, SAP (GUI and Netweaver) and DB2
• Watchdog Process:  provides a backup mechanism for recovery and diagnostics in the case of a daemon failure.

Communicating with Active Directory

To talk to domain controllers, the Centrify agent uses the following communication ports:

Port	Description
TCP/UDP 389	LDAP
TCP 3268	Global Catalog Search
TCP 88	Kerberos TGT
TCP 464	Kerberos password changes (passwd, adpasswd)
UDP123	Optional: Network Time Protocol (NTP)(*)
TCP 53	DNS query for A and SRV records
TCP 445	Optional:  SMB to read Group Policies
Ephemeral Ports	Required for communication

Communications between the Centrify client are mutually authenticated and encrypted, just like when Windows clients communicate with DCs.

For more information, see this Technet article.

(*) By default, the Centrify AD client will make UNIX, Linux or Mac sync time with Active Directory Domain Controllers;  you can use any NTP service, however you need to make sure that it's within 5 minutes from the DC (that acts as a Kerberos KDC).  This is a Kerberos requirement to protect against replay attacks.