Deploying Kerberos Authentication

Michelle Escalante

Product Manager

Novell, Inc.

Rajasekaran Nagarajan

Identity Management Access Engineer

Novell, Inc.

Agenda

Access management issues

Deploying Kerberos in your existing eDirectory™ environment

Integrating with existing Kerberos

Access Management

Access Management

The Goal

Right people get access the right information at the right time

Secure the information while making it accessible

The Problem

Many platforms, environments and applications

Many categories of users with different kinds of rights

Many types/purposes of access

No single, unified approach to managing/controlling all these things

What this means to your organization

Multiple vendor relationships

Big security holes, OR…

Duplicate administration, policies, skill sets, etc.

You play the role of bridge, traffic cop, translator…

One option
Kerberos

Kerberos v5

RFC 1510

MIT code base

Ticket based authentication system

Vendor agnostic OS authentication

*nix, Apple, Sun, MS, Novell

Widely supported application standard

Telnet, FTP, SAP, Oracle, Sybase, Xerox, Reflection, Cisco Routers

Kerberos
Web Browser

Mozilla http://www.mozilla.org/projects/netlib/integrated-auth.html

SPNEGO (RFC 2478)

negotiateauth extension http://negotiateauth.mozdev.org/

Leverages OS sytem library

Windows: SSPI

*ux, Mac OSX: GSS-API

Off by default for security

Whitelist of allowed sites

Configured by Admin at browser deployment

Apache

Mod_auth_kerb

Deploying Kerberos
In your existing eDirectory environment

Novell Kerberos KDC
Overview

Novell

Kerberos KDC

Kerberized

Application

Servers

Web Based

Management

Console

Workstation with Kerberos Client & Appln. clients

Authentication

& Tickets issue

LDAP

eDirectory

with

Kerberos

Realm Data

Application Access with Service Tickets

Novell Kerberos KDC
Architecture Components

KDC

Provides authentication and ticket granting services to Kerberos clients

Administration Server

Services administration requests

Password server

Services change principal's password requests from standard Kerberos Change Password clients

kadmin and kdb5_util

Command line tools for managing kerberos realms and principals in eDirectory

iManager Plug-in

For administration of Kerberos data in eDirectory

Kerberos LDAP Extensions

For storing and retrieving various Kerberos specific keys from eDirectory

Kerberos Password Agent

For synchronizing the Kerberos keys from Universal Password

Novell Kerberos KDC
Architecture (Contd...)

eDirectory

Kerberos Password Agent

Kerberos LDAP Extensions

kinit

kpasswd

kadmin

kdb5_util

KDC

Admin Server

Password Server

Kerberos Plug-in

LDAP Server

iManager

Web

Browser

DB2

LDAP

Novell Kerberos KDC
Architecture (Contd...)

eDirectory

Kerberos LDAP Extensions

DAL (krb5_db)

Database Abstraction Layer (DAL)

Created to work with various databases (including LDAP / eDirectory)

DB2

Core Library (krb5)

More Modules...

Administration API (kadm5)

kadmin.local

kdb5_util

Admin Server

Password Server

KDC

LDAP Server

Novell Kerberos KDC
Architecture (Contd...)

LDAP Over SSL

eDirectory

LDAP Server

KDC Server AS / TGS

LDAP Client

Authentication

Read Realm Data

Read

krbtgt/REALM@REALM

Key Data

TCP/UDP Port (88)

AS/TGS Request/Reply

KDC Host

LDAP Kerberos Extension

Read

Master Key

Trusted Root

Certificate

Password Stash

Configuration Data

Read Principal Data

NICI

Cryptographic Operations

Novell Kerberos KDC

KDC Platforms

Linux (SUSE®, RedHat)

Future NetWare®

eDirectory components (LDAP Extension and PW Agent)

8.7.3(+)

Linux and NetWare 6.5®

SDK for Kerberos developers

Deployment
Options and considerations

Novell

Kerberos KDC(s)

Realm(s) Information

Kerberos LDAP

Extensions & PW Agent

Client Workstation

2-20 Megs

Standard KRB

RFC 1510

Secure

LDAP

>15 Megs

Policy Aux Class

Principal Aux Class

ACME

An Entry starting

a subtree

(Can even be tree root)

Security Container

Kerberos Container

Realm Container

Policy Aux Class

Policy

KDC

Administration Service

Password Service

Legend

Kerberos Objects

eDirectory Objects

Kerberos data in eDirectory
Schema

m

n

n

n

n

1

m

1

Service Principal

An object representing a user

1

Kerberos data in eDirectory
An Example

Organization

Organizational

Unit

Security

Kerberos

Realm

Kerberos User Principal

CN: trace

krbPrincipalName: trace@MARKETING.ACME.COM

krbUPEnabled: TRUE

krbSecretKey: @#$%/*&^

o=acme

Kerberos Service Principal

krbPrincipalName: host/acme.srv1@MARKETING.ACME.COM

krbSecretKey: @#$%/*&^

ou=marketing

cn=Security

cn=Kerberos

Kerberos User Principal

CN: jsmith

krbPrincipalName: jsmith@MARKETING.ACME.COM

krbSecretKey: @#$%/*&^

ACME

cn=MARKETING.ACME.COM

Kerberos data in eDirectory
An Example (Contd.)

Organization

Organizational

Unit

Security

Kerberos

Realm

o=acme

ou=marketing

cn=Security

cn=Kerberos

ACME

cn=MARKETING.ACME.COM

Kerberos Realm

CN:	MARKETING.ACME.COM

krbMasterKey:	@#$%/*&

krbSubTree:	ou=marketing

krbSearchScope:	2

krbUPEnabled:	False

krbPrincNamingAttr:	CN

krbSupportedEncTypes:	DES-CBC-CRC

DES3-CBC-SHA1

AES128-CTS-HMAC-SHA1-96

AES256-CTS-HMAC-SHA1-96

krbDefaultEncType:	AES256-CTS-HMAC-SHA1-96

krbSupportedSaltTypes:	NORMAL

V4

NOREALM

ONLYREALM

SPECIAL

AFS3

krbDefaultSaltType:	NORMAL

krbKdcServers:	cn=KDC-mkt.acme.com,

ou=marketing,o=acme

krbLdapServers:	mkt.acme.com

Kerberos data in eDirectory
An Example (Contd...)

Organization

Organizational

Unit

Security

Kerberos

Realm

o=acme

ou=marketing

cn=Security

cn=Kerberos

Kerberos Ticket Policy

krbTicketFlags: 0

krbMaxTicketLife: 1 Day

krbMaxRenewableAge: 1 Week

ACME

cn=MARKETING.ACME.COM

Universal Password is enabled.

Extend Schema

Install and configure Novell KDC

Specify the principal naming attribute (cn, sn, uid, givenname, fullname, emailaddress)

Enable Universal Password to be as Kerberos passwords

Single password for both eDirectory user and the associated Kerberos principals and rich password policy

Universal Password is not enabled.

Extend Schema

Install and configure Novell KDC

Specify the principal naming attribute (cn, sn, uid, givenname, fullname,emailaddress)

Set Kerberos passwords for the principals

Deploying Kerberos
In your existing eDirectory environment

Integrating with existing Kerberos

Kerberos AuthN to Client32
NMAS Kerberos Method

NMAS enables using Kerberos tickets to authenticate to eDirectory

Integrates into a Kerberos based authN structure

Access to all the Client32 services

Work with any standards-based Kerberos

eDirectory changes can be minimal

Associate foreign principal name

Create eDir as service in existing realm

Configure realm and KDC in eDir

Integrating with AD & Client32 Logon
Using AD Kerberos

NMAS method

eDirectory is a Kerberized service in AD

eDirectory users are associated with AD users

Name space {foreign principal name field}

IdM AD Driver (future)

LDIF Import

User authenticates to KDC and then authenticates to eDirectory

Microsoft

Based on SIDs

Windows PAC attached to Kerberos ticket

Novell

Kerberos authN

Implemented by the application

Future extensions utilizing open standards

Authorization (AuthZ)

eDirectory changes can be minimal

Enable UP, chose a Principal name attribute

Kerberos cross-realm trust with 3rd party KDC

Regardless of primary AuthN, can obtain services in either realm

Integrating with 3rd party KDC
Using eDirectory Kerberos

/etc/passwd, /etc/shadow

NIS, NIS+

PAM (Pluggable Authentication Modules)

LDAP-compatible directories

Kerberos v5 (MIT, Heimdal, Novell)

PKI Certificates, smart cards

Integrating with Linux Logon

Kerberos integration using eDirectory

Common authentication credentials

Common policy for passwords, account lockout, management

Centralized identity information store

Kerberos cross-realm trust

Regardless of primary AuthN, can obtain services in either realm

Corporate identity using eDirectory Kerberos

3rd party realm applications work

Integrating Linux and eDirectory Logon AuthN

Kerberos for workstations

Windows

(login)

Application

SSPI

LSA

Credential

cache

Service

principal

key table

Application

GSSAPI

Kerberos

Default

Credential

(ticket) cache

Default Service principal

key table

Login

pam_krb5

kinit

klist

kdestroy

kpasswd

Standard 1510

Windows

Linux

RFC 1510-Kerberos V5

AS-Authentication Service

TGS-Ticket Granting Service

Kerberos Change password service

KRB

Summary

Access Managment

Deploying Kerberos in an existing eDirectory environment

Integrating with existing Kerberos

Integrating Linux workstations

BETA sign-up in the Brainshare lab

Summer 2005 release

References

•	Kerberos: The Network Authentication Protocol http://web.mit.edu/kerberos/www/

•	The Moron's Guide to Kerberos, Version 1.2.2 http://www.isi.edu/~brian/security/kerberos.html

•	Kerberos: An Authentication Service for Computer Networks http://www.isi.edu/gost/publications/kerberos-neuman-tso.html

•	RFC 1510 http://www.ietf.org/rfc/rfc1510.txt

•	Kerberos Working Group (krb-wg) http://www.ietf.org/html.charters/krb-wg-charter.html

Questions

Principal

Password

Novell

NMAS Kerberos Method (Contd...)

eDirectory

KDC

(MIT, MS, Heimdal, Novell)

iManager Plugin

for

NMAS Kerberos Method

NMAS Server

NMAS LSM

for

Kerberos

(KLSM)

Kerberos

Library

GSS API

Windows Workstation

NMAS Client

NMAS LCM

for

Kerberos

(KLCM)

Kerberos

Library

GSS API

User

Kerberized Services in the Network

MIT Services

MS Services

Novell Services

Novell Cache

MIT Cache

MS Cache

Novell

Password

Cross Realm Authentication
How it works

•Kerberos is a standard protocol that provides a means of authenticating entities on a network

•It is a trusted third party authentication protocol

•It involves shared secrets

•It uses symmetric key cryptography

•Kerberos protocol has three heads: a client, a server, and a trusted third party to mediate between them

•Originally developed at MIT’s Project Athena, Early 90s

Mod_auth_kerb is an Apache module designed to provide Kerberos authentication to the Apache web server. Using the Basic Auth mechanism, it retrieves a username/password pair from the browser and checks them against a Kerberos server as set up by your particular organization. The module also supports the Negotiate authentication method, which performs full Kerberos authentication based on ticket exchanges, and does not require users to insert their passwords to the browser. In order to use the Negotiate method you need a browser supporting it (currently standard IE6.0 or Mozilla with the negotiateauth extension).

The module supports both kerberos4 and kerberos5 protocols for password verification. The Negotiate mechanism can be only used with Kerberos v5. The module supports both 1.x and 2.x versions of Apache.

If you are using the Basic Auth mechanism, the module does not do any special encryption of any sort. The passing of the username and password is done with the same Base64 encoding that Basic Auth uses. This can easily be converted to plain text. To counter this, I would suggest also using mod_ssl or Apache-SSL. The use of SSL encryption is also recommended if you are using the Negotiate method.

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

Clients will be talking RFC 1510 Kerberos

KDC will be talking secure LDAP to the edirectory store where the user info is

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

A common scenario is existing eDir users who want to base their first Kerberos installation on their edirectory identities.

How do they get up and running in the least amount of time, with the most high-level configuration options – similar to how RADIUS is turned on by changing a few settings.

Create edir service allows edir to accept kerberos tickets for authentication

configure realm so that NMAS LCM knows which realm and which KDC to talk to

Can use Novell Gina – get MS tickets (because using MS KDC for auth will populate their cache)

Can't use ZEN GINA though

MS Gina – would require red “N” clicking

What MS has done is to extend the standard -

Kerberos is an authentication protocol

they do leave room to add functionality

however MS patented it and closed access to it, making a MS KDC mandatory

Novell's implementation of Kerberos is just authentication – pure 1510 compliant

We will likely extend support into authZ also – but via a standard mechanism and submit changes openly back to the standards organizations.

Two ways this could go:

MS Gina first

Novell NMAS Gina first

Novell Gina first – we take the novell user name and the kerberos PW – go to eDir and find the foreign prinicipal name – pass that to the KDC.

KDC grants a ticket, eDir takes that ticket for authentication

MS Gina first

User principal and user password – go to KDC – get ticket – send service ticket to eDir – auth to eDir based on ticket.

1.Client to TGS Local – request for a ticket to the remote TGS

2. TGS Local to Client- Reply with a ticket to the remote TGS

3. Client to TGS Remote – Request for a ticket to the remote Server

4. TGS Remote to client – reply with a ticket to the remote server

5. Client to Server Remote – request for service

2003-12-08T12:43:39

Michelle Escalante