Install and Configure an Open Source Identity Server Lecture · 2014. 4. 23. · SUSE05 & 06: Configure an Open Source Identity Server & Secure Access to Linux Services Copying all

Nove

Install and Configure an Open Source Identity ServerLecture

www.novel l .comNovell Training Services

AT T L I V E 2 0 1 2 L A S V E G A S

S U S 0 5 / S U S 0 6

ll, Inc. Copyright 2012-ATT LIVE-1-HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.

Novel

Legal Notices

Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.

Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.

Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.

Copyright © 2012 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.

Novell, Inc., has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or more additional patents or pending patent applications in the U.S. and in other countries.

Novell, Inc.

404 Wyman Street, Suite 500

Waltham, MA 02451

U.S.A.

www.novell.com

Online Documentation: To access the latest online documentation for this and other Novell products, see the Novell Documentation Web page (http://www.novell.com/documentation).

Novell Trademarks

For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/trademarks/tmlist.html).

Third-Party Materials

All third-party trademarks are the property of their respective owners.

Copying all or part of this manual, or distributing such copies, is strictly prohibited.To report suspected copying, please call 1-800-PIRATES.

Version 12

l, Inc. Copyright 2012-ATT LIVE-1-HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.

http://www.novell.com/info/exports/

http://www.novell.com/company/legal/patents/

http://www.novell.com/documentation

http://www.novell.com/company/legal/trademarks/tmlist.html

Copying all or part of this manual, or distributing such copies, is strictly prohibited. To report suspected copying, please call 1-800-PIRATES

Contents

SECTION 1: Configure an Open Source Identity Server 4

SECTION 2: Configure a LDAP Client 69

SECTION 3: Configure a Kerberos Client 75

SECTION 4: Configure SSH to Use Kerberos 81

SECTION 5: Integrate NFSv4 with Kerberos 85

Table of Contents

Novell, Inc. Copyright 2012-ATT LIVE-1-HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.

4

SUSE05 & 06: Configure an Open Source Identity Server & Secure Access to Linux Services


SUS03:Configure an OpenSource Identity ServerSection 1: Configure an Open Source Identity Server


5



Authentication and Security Methods and Transports

SASL

Kerberos

LDAPNFSv4Se

cure

Se

rvic

eP

roto

cols

Au

th.

Pro

vid

ers

Au

th.

Mec

hs

Cry

pto

Tech

s

x.509PKI

AESDES/3DESIDEA

Ciphers Hashes

RSA D-HDSA

Key Exchanges/Signatures

N-S

GSS-API

Au

th.

Pro

toc

ols

TLS/SSL SSH

Ses

sio

nE

ncr

ypti

on

Pro

toco

ls

Cry

pto

Me

tho

ds

Notes:


6



Cryptography Techniques

‒ Ciphers> Algorithms that perform encryption and

decryption> Can operate in either of two ways: encrypt

or decrypt> Provides security of data

‒ Key Exchanges and Signatures> Methods of generating and exchanging

keys used for signing data with a digital signature

> Provide authenticity of data‒ Hashes

> Algorithms that converts an arbitrary block of data and into a fixed length string

> Can operate in only one direction: encrypt> Provides verification of data integrity

BlowfishAESDES/3DESIDEA

RSA D-HDSAN-S

MD5SHA1

• Actions

Notes:


7



Authentication Protocols

• Kerberos‒ Kerberos is a strong authentication protocol that uses dynamic

centralized trusted 3rd party authentication> With Kerberos, the trusted 3rd party is the Key Distribution

Center (KDC)‒ Kerberos uses signed tickets as authentication tokens‒ With Kerberos, passwords never go across the wire‒ Kerberos only provides secure authentication. Session encryption

must be provided by another mechanism

Kerberos

Notes:


8



Authentication Mechanisms

• Generic Security Services API (GSSAPI)‒ GSSAPI is a native way for UNIX like OSES to access Kerberos

(and potentially other mechanisms) with a uniform API‒ GSSAPI can provide bothe authentication and session encryption

once authentication has peen performed‒ GSSAPI can be used by SASL as e mechanism to provide

authentication using Kerberos

GSS-API

Notes:


9



Authentication Providers

• Secure Authentication and Security Layer‒ SASL is a framework that sets up a system for authentication‒ SASL uses different “plug-in” mechanisms to perform the

authentication‒ SASL supports the negotiation of an encrypted session that can

be used by other protocols

SASL

Notes:


10



Session Encryption Protocols

• TLS/SSL‒ TLS (and its older implementation, SSL) is a method to provide

authentication and session encryption using keys and ciphers> TLS is most commonly used to provide session encryption.

Authentication is typically for entities rather than users‒ TLS uses a more static method of trusted 3rd party authentication

> With TLS, the trusted 3rd party is the Certificate Authority (CA)‒ TLS traditionally uses x.509 certificates as authentication tokens‒ TLS uses ciphers such as DES/3DES, AES, and IDEA to provide

encryption

TLS/SSL

Notes:


11



Session Encryption Protocols

• SSH‒ Secure Shell (SSH) is a protocol that provides a secure channel of

communication between devices on a network‒ SSH provides for secure “CRAM” authentication as well as token

passing authentication> SSH uses password authentication through its secure

communication channel> SSH uses PKI for password-less authentication

‒ SSH authenticates not only users but also the network devices (machines)

‒ SSH natively provides shell access and file transfer services‒ Any other protocol can be tunneled through SSH to leverage its

secure communications channel

SSH

Notes:


12



Secure Service Protocols

• OpenLDAP‒ OpenLDAP uses SSL and/or TLS (via SASL) to provide

session encryption‒ OpenLDAP can also use SSL and/or TLS to provide

authentication of both the client and the server

LDAP

Notes:


13



Secure Service Protocols

• NFSv4‒ The newest version of the NFS protocol‒ NFSv4 can use GSSAPI to restrict access to NFS exports‒ NFSv4 can use GSSAPI to provide session encryption of the

NFS traffic

NFSv4

Notes:




14

Introduction to TLS/SSL

Objective 1


15




• What is TLS/SSL‒ TLS/SSL is a session encryption protocol that uses Certificate

Authorities as a trusted third party‒ Certificate Authorities generate X.509 Certificates for use as

authentication tokens‒ Certificate Authorities generate encryption keys for encryption

and verification of data‒ TLS (Transport Layer Security) is the newest implementation of

and replacement for SSL (Secure Sockets Layer)> TLS allows for both secure an insecure communication

using a single port> SSL requires a second port to be used for the secure

communication

Notes:


16




• Certificate Authorities‒ Commercial

> Commercial Certificate Authorities (CAs) act as generally recognized trusted 3rd parties

> Commercial CAs generate certificates and keys at a cost to the user

> Commercial CAs should be used if you are conducting business with third parties outside of your organization or over the Internet

> For commercial CAs to be useful, their CA certificates must be commonly available. This is usually done by distributing them bundled with common web browsers

‒ Self Signed> You may create your own “self signed” Certificate Authority

with utilities such as OpenSSL> Self Signed CAs are used if you only need to provide

security and authentication inside your organization

Notes:


17




• TLS/SSL Authentication‒ TLS/SSL supports both unilateral and bilateral authentication

> Unilateral authentication is where only the server authenticates itself to the client

> Bilateral authentication is where both the client and the server authenticate to each other

‒ Unilateral authentication is provided by generating a server certificate and key

‒ Bilateral authentication is provided by also generation a client certificate and key

It is important to remember that authentication in the sense of TLS/SSL is that the client can verify the authenticity of the server's certificate. This does not mean that the server has been identified to the end user. The end user must manually verify the identity of the server by evaluating the information contained in the server's certificate along with it's CA-chain (the chain of Certificate Authority certificates that signed the server's certificate).


18




• TLS/SSL Phases‒ Peer negotiation

> Client and server negotiate the cipher suites, key exchange, and authentication algorithms to use

‒ Key Exchange and Authentication> Encryption keys are exchanged and entity authentication is

performed> Key exchange is performed using PKI> The certificates contain the public key

‒ Symmetric cipher encryption and message authentication> A symmetric key is generated (master secret) and

exchanged and is used for all further data uses this session's master secret

Notes:


19




• Open Source TLS/SSL Implementations‒ OpenSSL

> The most common open source implementation of TLS/SSL> Published under the OpenSSL& SSLeay licenses.

Completely open source but not GPL compatible‒ GnuTLS

> An alternate open source implementation of TLS/SSL that is published under the LGPL

Notes:




20

TLS/SSL Files and Directories

Objective 1


21



SUSE OpenSSL Server Directory Structure

/etc/ssl/ |-openssl.cnf (openssl configuration file) |-certs/ |-(all common Root CA certificates) |-(any other CA certificates) |-private/ |-(any keys) |-servercerts/ |-servercert.pem (common server certificate) |-serverkey.pem (common server key)

The /etc/ssl/ directory is where the local instance of OpenSSL stores information such as its own certificates and keys as as well as any CA certificates that have been installed.


22



YaST OpenSSL CA Directory Structure/var/lib/CAM/CA_Name/ |-cacert.key |-cacert.pem |-cacert.req |-cam.txt |-crlnumber |-index.txt |-openssl.cnf.tmpl |-.rand |-serial |-certs/ |- |-crl/ |-crl.pem |-keys/ |- |-newcerts/ |- |-req/ |-

The Certificate Authority directory structure is where all the files related to the Certificate authority are stored.

Important Files:cacert.key: The Certificate Authority's keycacert.pem: The Certificate Authority's certificatecacert.req: The Certificate Authority's certificate requestindex.txt: List of certificates generated by the CA and their statusserial: Contains a number representing the number of certificates generated. This is

incremented each time a certificate is generatedcrlnumber: Contains a number representing the number of of CRLs generated. This is

incremented each time a CRL is generatedopenssl.cnf.tpl: Contains the values (organization name, country code, etc.) used for the

Certificate Authority

Important Directories:certs: Directory containing the generated certificatesnewcerts: Directory containing an indexed internal copy of signed certificateskeys: Directory containing keys for the generated certificatescrl: Directory containing the Certificate Revocation Listreq: Directory containing the certificate request files




23

Introduction to OpenLDAP

Objective 1


24



What is LDAP?

• Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information in a Directory. ‒ An LDAP Directory can be used to store many types of

information.

‒ LDAP is a standardized open protocol.

Lightweight Directory Access Protocol (LDAP) is a set of protocols designed toaccess and maintain information in a Directory. An LDAP Directory can be used to store many types of information including user, group, and service configuration settings.

LDAP is a standardized open protocol, which ensures that many different clientapplications can access the information stored in the Directory.While there are a variety of LDAP-compliant directories that you could implement on a Linux server (including Novell eDirectory), we’re going to focus on OpenLDAP in this section.

An LDAP Directory uses a hierarchical tree structure. All entries (called objects) in the Directory have a defined position within its hierarchy.The complete path from the root of the tree to a particular entry, including the entry’s name, is called its distinguished name or DN. The DN uniquely identifies an object in the Directory tree.


25



To designate an entry relative to some point in the tree (not from the root of the tree), the object’s relative distinguished name or RDN is used. Objects can be categorized into one of two possible types:

Container objects: Container objects can contain other objects. They are like branches within the Directory tree.

Container object classes include the following:● root:

● The root element of the Directory tree. ● In LDAP, there is no actual object that represents the tree root.

NOTE: The tree root is also called the root entry.● dc (dcObject):

● Represents an element of your domain. ● It can represent any part of a domain name. ● For example: dc=digitalairlines,dc=com.

● c (country):● Represents a country. ● For example: c=US.

● o (organization):● Represents an organization. ● For example: o=DA.

● ou (organizationalUnit): ● Represents a division, department, team, or other functional group within an organization.

Leaf objects:Leaf objects are like leaves at the end of tree branches. They have no subordinate objects. Leaf objects usually represent a physical network resource.

Examples include the following:● InetOrgPerson:

● Represents a single user.● groupofNames:

● Represents a group.


26



An LDAP Directory

Unlike a real tree, a Directory tree is inverted. The top of the Directory tree is the tree root. The bottom of the tree are the leaf objects. The tree root can contain one of the following objects:●c (country)●dc (domain component)●o (organization)

There are two commonly used tree strategies for defining the top of the Directory tree.The first uses domain component objects to define the top of the tree hierarchy.Beneath the domain components are organizational units that define logicalgroupings of Directory objects. Consider the following example:Notice in the figure above that dc=digitalairlines,dc=com together defines the top layer of the tree hierarchy, not dc=com by itself.

Alternatively, you could also define the top of the tree hierarchy using country(optional), organization, and organizational unit objects. If desired, you can create a country object at the top of the tree and then create one or more organization objects within the country object. You can also omit the country object and simply create an organization object at the top of the tree.An example of this tree design is shown in the figure below:

Either strategy is acceptable. Generally speaking, administrators who have priorexperience with Microsoft Active Directory tend to favor using domain componentsat the top of an OpenLDAP Directory tree.NOTE: The use of domain components is the default structure used by OpenLDAP.Those coming from a Novell eDirectory background tend to favor using organization objects at the top of the tree.


27



Terminology (1/2)

Schema -Defines Object Classes and their Properties

Object Class -Defines a list of properties , both required and optional,

that can be used to describe an object

Object -An instance in a directory

Property -A piece of information that describes an object

-Available to assigne to an object when the object is a

member of an Object Class that describes the property

Value -The data stored in a property

Notes:


28



Terminology (2/2)

Context -An object's position in the directory tree

Distiguished Name (DN)

-The absolute (contextful) name of an object in the tree

Example: cn=bsmith,ou=people,dc=example,dc=com

Relative Distiguished Name (RDN)

-The (contextful) name of an object relative to your

current context

Example: cn=bsmith

Notes:


29



OpenLDAP

• OpenLDAP:‒ Is an Open Source LDAP server

‒ Has three main components> LDAP server daemon

> LDAP libraries

> LDAP client utilities

‒ Supports multiple data storage back ends

Notes:


30



OpenLDAP Architecture

LDAP Request

Front End Overlay Stack Back End

Front End:Recieves and decodes the LDAP request and passes it on to the Back End to processed

Overlay Stack:Code that can site between the front and back end that intercepts the decoded request and/or reply and triggers action(s)Examples:

accesslog: log activety to another LDAP database for accessibility loggingauditlog: log server activity to a flat text file for accessibility loggingconstraint: restrict acceptable values for particular attributesetc.

Back End:Interfaces with a database, proxy or dynamic backend

Database - Actually contains dataProxy - Gateway to another data storage systemDynamic - Generate data on the fly


31



OpenLDAP Files and Directories

/etc/openldap/ -Main configuration directory

/etc/openldap/slapd.conf -Legacy configuration file

-No longer used. Replaced by cn=config

database

/etc/openldap/slapd.d/ -Configuration database directory

cn=config/

cn=config.ldif

/etc/openldap/schema/ -Directory containing alvailable schema

files

/etc/openldap/ldap.conf -LDAP client configuration file

/var/lib/ldap/ -Directory containing the LDAP database

files

Notes:


32



LDAP CLI Utilities

ldapsearch -used to query/search the LDAP database

-uses the LDAP protocol for communication

-returns information in LDIF format

ldapadd -used to add objects to the LDAP database

-ojgects to be added are in LDIF format

ldapdelete -use to delete objects for the LDAP database

-refferenced by their DN

ldapmodify -used to modify properties of objects in the LDAP

database

ldappasswd -used to change passwords in a LDAP database

Notes:


33



cn=config Layout

cn=config

|-cn=schema(,cn=confg)

| |-cn={0}core(,cn=schema,cn=confg)

| |-cn={1}cosine(,cn=schema,cn=confg)

|

|-olcDatabase={-1}frontend(,cn=confg)

|

|-olcDatabase={0}config(,cn=confg)

| |-olcOverlay=syncprov(,olcDatabase={0}config,cn=confg)

|

|-olcDatabase={1}hdb(,cn=confg)

| |-olcOverlay=syncprov(,olcDatabase={1}hdb,cn=confg)

Notes:


34



cn=config LDIF

dn: cn=config

objectClass: olcGlobal

cn: config

olcArgsFile: /var/run/slapd/slapd.args

olcAuthzRegexp:

{0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth

dn:cn=config

olcLogLevel: none

olcPidFile: /var/run/slapd/slapd.pid

olcSizeLimit: 10000

olcTLSCACertificateFile: /etc/ssl/certs/YaST-CA.pem

olcTLSCertificateFile: /etc/ssl/servercerts/servercert.pem

olcTLSCertificateKeyFile: /etc/ssl/servercerts/serverkey.pem

olcServerID: 1 ldap://ds1

olcServerID: 2 ldap://ds2

Notes:


35



olcDatabase={0}config LDIF

dn: olcDatabase={0}config,cn=config

objectClass: olcDatabaseConfig

olcDatabase: {0}config

olcAccess: {0}to * by dn.base="uid=syncrepl,ou=system,dc=site" read by * break

olcLimits: {0}dn.exact="uid=syncrepl,ou=system,dc=site" size.soft=unlimited

olcRootDN: cn=config

olcRootPW: {SSHA}e7U5lc4WgB5JStvI/xScDk5QL6xBVlNSRw==

olcSecurity: simple_bind=128 ssf=71

olcSyncrepl: {0}rid=1 provider="ldap://ds1/" searchbase="cn=config"

type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand

bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=site"

credentials="zZHto3wNTN4M"

olcUpdateRef: ldap://ds1/

Notes:


36



olcDatabase={1}hdb LDIF (1/3)dn: olcDatabase={1}hdb,cn=config

objectClass: olcDatabaseConfig

objectClass: olcHdbConfig

olcDatabase: {1}hdb

olcDbDirectory: /var/lib/ldap

olcSuffix: dc=site

olcAccess: {0}to * by dn.base="uid=syncrepl,ou=system,dc=site" read by * break

olcAccess: {1}to attrs=userPassword by self write by * auth

olcAccess: {2}to attrs=shadowLastChange by self write by * read

olcAccess: {3}to attrs=userPKCS12 by self read by * none

olcAccess: {4}to * by * read

olcLimits: {0}dn.exact="uid=syncrepl,ou=system,dc=site" size.soft=unlimited

olcRootDN: cn=Administrator,dc=site

olcRootPW: {SSHA}KGOL0YlXGxSy6qAekekobq6e055NU0xTTw==

...

Notes:


37




...

olcSyncrepl: {0}rid=2 provider="ldap://ds1/" searchbase="dc=site"




olcSyncrepl: {0}rid=3 provider="ldap://ds2/" searchbase="dc=site"




olcMirrMode=TRUE

olcUpdateRef: ldap://ds1/

olcDbCacheSize: 10000

olcDbCheckpoint: 1024 5

olcDbIDLcacheSize: 30000

...

Notes:


38




...

olcDbIndex: objectclass eq

olcDbIndex: uidNumber eq

olcDbIndex: gidNumber eq

olcDbIndex: member eq

olcDbIndex: memberUid eq

olcDbIndex: mail eq

olcDbIndex: cn eq,sub

olcDbIndex: displayName eq,sub

olcDbIndex: uid eq,sub

olcDbIndex: sn eq,sub

olcDbIndex: givenName eq,sub

olcDbIndex: entryUUID eq

olcDbIndex: entryCSN eq

Notes:


39



olcOverlay=syncprov

dn: olcOverlay={0}syncprov,olcDatabase=DATABASE,cn=config

objectClass: olcSyncProvConfig

olcOverlay: {0}syncprov

olcSpCheckpoint: 100 10

Notes:




40

OpenLDAP Replication

Objective 1


41



OpenLDAP Sync Replication

• OpenLDAP supports synchronization of the LDAP database between multiple servers using sync replication (i.e. syncrepl)

• Methods:‒ Single master - multiple slave

‒ N-Way Multimaster

‒ MirrorMode

Syncrepl LDAP Replication:

Single-master - multiple slaveSingle master - multiple slave replication supports, as the name implies, only a single master LDAP server. The Master LDAP server is where all changes to the LDAP database are made and then a copy of the database is replicated out to the slave server(s). If a client attempts to write to a slave server the slave server refers the write to the master server.This mode provides for the highly available LDAP reads but not highly available LDAP writes. Because there is only a single master (changeable copy) of the LDAP database, this mode provides the best data consistency guarantees.

An alternate form of replication can be used with this model called Delta-syncrepl. With delta-syncrepl replication only the bits of the LDAP database that have changed are replicated tho the slave servers. This can dramatically speed up LDAP replication transfers with a large LDAP database

N-Way MultimasterN-Way multimaster replication allows for multiple master LDAP servers each with their one changeable databse. This mode provides for both highly available LDAP reads and writes but does not provide as high of data consistency guarantees.

N-Way multimaster replication does not provide load balancing because all writes must be replicated to all LDAP master servers


42



MirrorModeMirrorMode replication is a hybrid between Single Master and N-Way Multimaster replication and shares the advantages of both modes.

With MirrorMode replication a single server is denoted as the “Primary Master” server. This is the server that all writes are performed on during normal operation. If a client attempts a write to one of the other “Master” servers they refer the write to the Primary Master server instead. The Primary Master server then replicates is database out to all other servers. The other “replica” LDAP servers then operate as slave servers during normal operation. Therefor during normal operation MirrorMode operates as if it were a Single Master - Multiple Slave configuration and has the advantages of that mode (highly available reads, data consistency guarantees, etc.) In the case of a failure of the primary master server, each “replica” server can act as a master server and write to the LDAP database, replicating these changes between each other. In this case, the replication is acting as if were N-Way multimaster and has the advantages of that mode (highly available read and writes, etc.).

In the case of a failure of the Primary Master server, when the primary master server comes back on-line, the “replica” servers replicate all of their changes back to the primary master server and it takes over the role of “Primary Master” again.




43

Introduction to Kerberos

Objective 1


44



Kerberos

• Strong authentication protocol that uses dynamic, centralized, trusted 3rd party authentication

• Used signed tickets as authentication token

• Never sends passwords over the wire

• Only provides secure authentication‒ Session encryption is provided by another mechanism

Kerberos

Notes:


45



Terminology (1/2)

KDC -Key Distribution Center

-Maintains the Kerberos database

-Provides Ticket Granting Tickets (TGT)

Ticket -Signed authentication token used to gain access to

kerberized a service

TGT -Ticket granting Ticket

Ticket Session Key

-Key associated with and validates a TGT

-Used to request a serivce ticket

Credential -Combination of the TGT and Ticket Session Key

-Authenticates a user when requesing access to a

kerberized service

-Stored in the credential cache on the client

Notes:


46



Terminology (2/2)

Credential cache

-Where credentials and service tickets are stored

on a client

-Typically a file in /tmp

Keytab -File on a host that contains the host and service

principal keys for that host

Realm -Logical network service by a KDC (or set of KDCs if

replication is configured)

-typically the same as the Internet Domain

-represented in all CAPS to diferentiate it from the

Internet domain

TGS -Ticket Granting Service

-Grants service tickets to clients for access to

kerberized network services

Notes:


47



Kerberos Principals

• Entry in the Kerberos Database‒ primary/instance@REALM

• Types:‒ User: Used for users to authenticate and get tickets

> Passwords (keys) are stored in the Kerberos database

> bob/[email protected]

‒ Host: Used for machines to validate tickets> keys (passwords) are stored in the kerberos database and in a keytab on the host

> host/[email protected]

‒ Service: Used for machines to validate tickets> keys (passwords) are stored in the kerberos database and in a keytab on the host

> nfs/[email protected]

Notes:


48



Obtain a Kerberos Ticket

KDCprocess

TGSprocess

TGT

TSK

Kerberos Client

Credential Cache

1. kinit

Kerberos Server

KerberosDatabase

2. TGT &

Key G

ranted

Process for obtaining a Kerberos ticket:

1. Kinit● The kinit program sends a request to the Key Distribution Center (KDC) requesting a ticket for a user principal●The kinit program asks the user for their password and stores it for later use. (The user's password is not sent to the KDC)

2. TGT Granting●The KDC checks the Kerberos database for a principal that matches the one requesting a ticket●A Ticket-Granting Ticket (TGT) and corresponding Ticket Session Key is generated for the principal and the TGT is encrypted with the user's password (as retrieved form the Kerberos database)●The TGT and Ticket Session Key are sent back to the kinit command and the the kinit command decrypts the TGT with the password it requested from the user.●The TGT and Ticket Session Key are then stored in the Kerberos client's credential cache

The TGT and its associated key are created with a specific lifespan. The TGT can be renewed any time during that time period and if it expires a new TGT can be requested.

Kerberos is a very time sensitive protocol and therefor require that all Kerberos clients and servers have their time synchronized.


49



Access a Kerberized Network Service

KDCprocess

TGSprocess

ServiceTicket

TGT

TSK

Kerberos Client

Credential Cache

TGTServiceTicket

Kerberos Server

KerberosDatabase

1. P

rese

nt

TG

T t

o T

GS

2. Ob

tain

service ticket 3. P

rese

nt

serv

ice

ticke

t

KerberizedNetworkService

Host/Svc key

keytab

Process for gaining access to a kerberized network service:

1. Client Request●The Kerberos client application presents the TGT to the Ticket Granting Service (TGS) and requests a service ticket for the desired network service

2. Service Ticket granting●The TGS checks the Kerberos database for a host and/or service principal matching the request and the generates a ticket that grants access to that service. The service ticket is encrypted with the host/service principal's key and then sent back to the Kerberos client●The Kerberos client stores the service ticket in its credential cache

3. Service Request●The Kerberos client application presents the service ticket to the kerberized network service●The kerberized network service decrypts the ticket using the host/service key stored in its keytab an then grants the Kerberos client application access to the service.

It is very important the the Kerberos client the the server providing the kerberized network service have their time in sync because of the time sensitive nature of the Kerberos protocol.




50

MIT Kerberos Files and Directories

Objective 1


51



Important Files and Directories

/etc/krb5.conf -contains kerberos configuration information such as

realm, KDC and asmin servers, etc.

/var/lib/kerberos/krb5kdc/kdc.conf

-contains KDC configuration information

/var/lib/kerberos/krb5kdc/.k5.<REALM>

-key stash file use by the KDC to authenticate itself

to the database utilities (kadmin,krb5kdc, etc.)

/var/lib/kerberos/krb5kdc/kadm5.keytab

-keytab containing the kadmin principal key

-used when using kadmin.local

/etc/init.d/krb5kdc (symlink: /usr/bin/rckrb5kdc)

-init script that starts the Kerberos KDC daemon

/etc/init.d/kadmind (symlink: /usr/bin/rckadmind)

-init script that starts the Kerberos kadmin daemon

Notes:


52



View Kerberos Objects in LDAP

Notes:


53



Kerberos Daemon Binaries

/usr/lib/mit/sbin/krb5kdc

-KDC server daemon binary

/usr/lib/mit/sbin/kadmind

-kadmin daemon binary

Notes:


54



Common Kerberos CLI Utilities

kadmin / kadmin.local

-main Kerberos database administration utility(s)

-kadmin.local is run on the KDC and authenticates

with a keytab

-kadmin can be run anywhere but requires authentication

ktlist -lists the keys contained in a keytab ktlist: rkt <keytab_file>

ktlist: list

kpasswd -changes the password (user principal key) for a

Kerberos user (user principal)

kinit -used to request a ticket from the KDC

Notes:




55

Create and Modify Kerberos Principals

Objective 1


56



Kerberos Principals

• Host and Service Principals:‒ used to validate access to a network serivce

‒ created with kadmin

‒ have a randomly generated key

‒ store this key locally in a keytab file

• User Principals:‒ used when logging in and accessing network services

‒ created with kadmin

‒ key is used and managed as a password

Notes:


57



Create Host/Service Principal

KDCprocess

TGSprocess

KerberizedNetworkService

Kerberos Server

KerberosDatabase Host/Svc key

keytab

1. kadmin.local: addprinc -randkey <principal>

2. kadmin.local: ktadd -k <keytab> <principal>

3. scp <keytab> <host>:/etc/krb5.keytab

Add a host or service principal to the Kerberos database

1. kadmin.local●Use the kadmin.local utility to create a host or service principal and generate a random key kadmin.local -q “addprinc -randkey host/<hostname>”

● addprinc: add new principal● -randkey: generate a random key for the host

2. Generate a keytab for the Host●Use the ktadd option of the kadmin.local utility to copy the host or service principal's key into a keytab file

3. Copy keytab to host●Use scp copy the keytab to the hosts' keytab (/etc/krb5.keytab)


58



Create/Modify User Principal

KDCprocess

TGSprocess

Kerberos Server

KerberosDatabase

1. Create User Principal kadmin.local: addprinc <principal>

2. Change Principal Password kadmin.local: cpw <principal> or kpasswd <username>

Add a user principal to the Kerberos database

1. kadmin.local●Use the kadmin.local utility to create a host or service principal and generate a random key kadmin.local -q “addprinc <username>”●The user principal password is set initially when the principal is created

2. Change user principal password●Use the kadmin.local or kpasswd to change the user principal passwordkadmin.local: cpw <username>orkpasswd <username>


59



LAB 2-1: Configure an SSL Certificate Authority with YaST

Summary: In this exercise you use YaST to configure a Certificate Authority.

Special Instructions:

Use the following values in the exercise:

CA_NAME=Site_CA

CA_COMMON_NAME=Site_CA

CA_EMAIL=postmaster@site

CA_PASSWD=linux

Duration: 10 min.

DS2DS1

&

Lab Notes:


60



LAB 2-2: Configure csync2 for the Certificate Authority

Summary: In this exercise, you configure csync2 to keep the common certificate authority configuration file synchronized between the CA servers.

Special Instructions


Duration: ? min.

DS2DS1

&

Lab Notes:


61



LAB 2-3: Generate a Common Server Certificate with YaST

Summary: In this exercise you use YaST to generate a server certificate and the export it as the common server certificate.



CA_PASSWD=linux

CRT_COMMON_NAME=ds1

CRT_EMAIL=postmaster@site

Duration: 10 min.

DS1

Lab Notes:


62



LAB 2-4: Generate a Server Certificate for the DS2 Server

Summary: In this exercise you use YaST to generate a server certificate for a the DS2 server.



CA_PASSWD=linux

DS2_FQDN=ds2


CRT_FILENAME=node1_crt.pem

Duration: 10 min.

DS2DS1

&

Lab Notes:


63



LAB 3-1: Configure an NTP Server on the LDAP Servers

Summary: In this exercise, you configure timesync on the LDAP server with NTP.



DS1_IP= 172.17.2.16

Duration: ? min.

DS2DS1

&

Lab Notes:


64



LAB 3-2: Configure an OpenLDAP Master Server

Summary: In this exercise, you .



BASE_DN= dc=site

ADMIN_DN= cn=Administrator

ADMIN_DN_PASSWD= novell

Duration: ? min.

machineDS1

Lab Notes:


65



LAB 3-3: Configure an OpenLDAP Slave Server




BASE_DN= dc=site


ADMIN_DN_PASSWD= novell

Duration: ? min.

DS2

Lab Notes:


66



LAB 3-4: Configure OpenLDAP Multi-master Replication




BASE_DN= dc=site

Duration: ? min.

DS1

Lab Notes:


67



LAB 4-1: Configure a Primary Kerberos Server with an LDAP Back End

Summary: In this exercise, you configure a primary Kerberos servers that use an LDAP back end for the Kerberos database.



KRB5_REALM= SITE

KRB5_PASSWD= linux

BASE_DN= dc=site


ADMIN_DN_PASSWD= linux

DNS_DOMAIN= site

HOSTNAME= (machine hostname)

Duration: ? min.

DS2DS1

&

Lab Notes:


68



LAB 4-2: Configure csync2 for the Kerberos Servers

Summary: In this exercise, you configure csync2 to keep the Kerberos configuration synchronized between the Kerberos servers.



Duration: ? min.

DS2DS1

&

Lab Notes:


69



LAB 4-3: Configure a Secondary Kerberos Server with an LDAP Back End

Summary: In this exercise, you configure a secondary Kerberos servers that use an LDAP back end for the Kerberos database.



KRB5_REALM= SITE

KRB5_PASSWD= linux

BASE_DN= dc=site


ADMIN_DN_PASSWD= linux

DNS_DOMAIN= site


Duration: ? min.

DS2DS1

&

Lab Notes:


70



SUS03:Configure an OpenSource Identity ServerSection 2: Configure a LDAP Client


71



LAB 2-1: Generate a SSL Certificate for Another Server

Summary: In this exercise you use YaST to generate a server certificate for another server.



CA_PASSWD=linux

DS2_FQDN=node1


CRT_FILENAME=node1_crt.pem

Duration: 10 min.

DS2DS1

&

Lab Notes:


72



LAB 2-2: Import a Common Server Certificate for a Server

Summary: In this exercise you use YaST to import a certificate as the common server certificate.



CRT_FILENAME=node1_crt.p12

Duration: 10 min.

Node1

Lab Notes:


73



LAB 2-3: Configure a LDAP Client with YaST

Summary: In this exercise, you configure the LDAP client on the LDAP/Kerberos servers.



BASE_DN= dc=site


Duration: 5 min.

Node1

Lab Notes:


74



LAB 2-4: Create LDAP Groups and Users




BASE_DN= dc=site


Duration: 5 min.

DS2DS1

or

Lab Notes:


75



SUS03:Configure an OpenSource Identity ServerSection 3: Configure a Kerberos Client


76



LAB 3-1: Configure an NTP Client

Summary: In this exercise, you configure timesync on the Kerberos client with NTP.



DS1_IP= 172.17.2.16

Duration: 5 min.

DS2DS1

&

Lab Notes:


77



LAB 3-2: Create LDAP Group and Users for Kerberos

Summary: In this exercise, you create a LDAP group and user accounts for use with Kerberos.



(none)

Duration: 5 min.

machineDS1

Lab Notes:


78



LAB 3-3: Create Kerberos User Principals

Summary: In this exercise, you create Kerberos user principals.



(none)

Duration: 5 min.

machineDS1

Lab Notes:


79



LAB 3-4: Configure a Kerberos Client with YaST

Summary: In this exercise, you configure the Kerberos client on the LDAP/Kerberos servers.



KRB5_REALM= SITE

DNS_DOMAIN= site


Duration: 5 min.Node1

Lab Notes:


80



LAB 3-5: Configure PAM to Use Both LDAP and Kerberos

Summary: In this exercise, you configure PAM to use both LDAP and Kerberos for user authentication.



Duration: 5 min.

Node1

Lab Notes:


81



SUS04:Secure Access to Linux ServicesSection 4: Configure SSH to Use Kerberos


82



Objectives

• SSH and Kerberos Authentication


83



LAB 4-1: Create Host Principals and Keytabs for the Kerberos Servers

Summary: In this exercise, you configure create host principals and the generate keytabs for the Kerberos servers.



(none)

Duration: ? min.

DS2DS1

&

Lab Notes:


84



LAB 4-2: Configure SSH on the Kerberos Server to use Kerberos Authentication

Summary: In this exercise, you configure the ssh daemon to use Kerberos tickest for authentication.



(none)

Duration: ? min.

DS2DS1

&

Lab Notes:


85



Integrate Linux Services with SSL, LDAP, and KerberosSection 5: Integrate NFSv4 with Kerberos




86

Introduction to NFSv4

Objective 1


87



NFSv4 Improvements

• NFSv4 offers a wide range of improvements in areas such as:‒ Performance

‒ Security

‒ Interoperability

• NFSv4 is backward compatible with NFSv2/v3‒ (depending on server/client implementation)

Notes:


88



Performance Improvements

• Uses stateful rather than stateless operations‒ client uses statae to notify the server of its intentions on a file

‒ server can return information to clients about other client's intentions

• Uses TCP for transport by default‒ Requires only a single well-known port (tcp:2049) for communication

• Uses compound RPC calls‒ several NFS operation can be inclided in a single RPC request

• Single NFS daemon‒ nfsd encompases all features/funcionality of v2/v3 suite of daemons

Notes:


89



Security Improvements

• Client-server interactions now secured with GSS-API‒ level of security can be determined (auth, interactions, full session)

• UID to user name mapping‒ users are passed as a string (user@domain) rather than a UID

• Supports ACL authorizations in addition to UNIX permissions

Notes:


90



Interoperability Improvements

• Exports a single “pseudo file system” rather than multiple file systems‒ other directories/file system are bind mountes into the pseudo root

• Supports ACLs that are both POSIX and Windows compatible

• Mandatory and advisory locking of file is now supported‒ locking is lease-based

Notes:




91

Important NFS Files and Directories

Objective 1


92



Important Files and Directories

/etc/exports -contains the list of exported file systems

/etc/idmap.conf -contains information about the IDmap domain and

specific ID mappings such as the nobody user/group

/etc/sysconfig/nfs

-contains variables used by the nfsserver and nfs init

scripts that determini the behavior of the daemons

-some variable determine which daemons to start

/etc/init.d/nfsserver

-init script that starts the NFS server daemons

/etc/init.d/nfsclient

-init script that starts the NFS client daemons

Notes:


93



NFS Daemon Binaries (1/2)

/usr/sbin/rpc.nfsd

-main userspace utility (a.k.a. nfsd)

-in NFSv4 it contains/provides all the functionalities

of the v2/v3 rpcbind, lockd, rpc.statd daemons

-resposible for starting/stopping nfs kernel threads

-runs on server

/usr/sbin/rpc.mountd

-receives and verifies mount requests

-not used for any over-the-wire operations in NFSv4

-runs on both server and client

/usr/sbin/rpc.idmapd

-NFSv4 ID <--> name mapping daemon

-runs on server

Notes:


94



NFS Daemon Binaries (2/2)

/usr/sbin/rpc.svcgssd

-provides transport mechanism for the authentication

process on the server

/usr/sbin/rpc.gssd

-provides transport mechanism for the authentication

process on the client

Notes:


95



Common NFS CLI Utilities

exportfs -maintains a list of exported file systems

-used to apply changes to exported file systems

without restarting NFS daemons

showmount -displays mount/export information for a remote host

Notes:




96

NFSv4 Security

Objective 1


97



NFSv4 Security

• NFSv4 security uses the GSS-API framework

• The GSS-API framework supports multiple authentication plug-ins‒ Kerberos

‒ LIPKEY

‒ SPKM-3

• The quality of the protection can be configured‒ Authentication

‒ Integrity checking

‒ Full privacy

Notes:


98



NFSv4 Security Configuration

• NFSv4 ID mapping requires user names to be the same on the server and the client‒ Centralized management of usernames can be provided by LDAP

• NFSv4 security requires Kerberos to be configured‒ When using the Kerberos GSS-API plug-in

• Kerbeors requires time synchronization

Notes:


99



LAB 5-1: Generate a Host Principal and a Keytab for an NFS Server

Summary: In this exercise, you generate a host and service principal for the NFSv4 server and then export the host and service keys into a keytab file on the the server.



NFS_HOSTNAME= storage1

Duration: ? min.Storage1DS1

&

Lab Notes:


100



Node1

LAB 5-2: Generate a Host Principal and a Keytab for Kerberos Clients

Summary: In this exercise, you generate a host principal for the NFSv4 client(s) and then export the host key into a keytab file on the the client(s).



KRB5_CLIENT= (hostname of client machine)

Duration: ? min.

&

DS1

Lab Notes:


101



LAB 5-3: Configure an NFSv4 Server with GSSAPI

Summary: In this exercise, you configure an NFSv4 server with GSS security enabled.



DNS_DOMAIN= site

Duration: ? min.

storage1

Lab Notes:


102



LAB 5-4: Configure an NFSv4 Client with GSSAPI

Summary: In this exercise, you configure an NFSv4 client.



DNS_DOMAIN= site

NFS_SERVER= storage1

Duration: ? min.

node1

Lab Notes:


103



LAB 5-5: Export /home with NFSv4 and GSSAPI

Summary: In this exercise, you export /home as a part of the NFSv4 “pseudo file system” with GSS security enabled.



(none)

Duration: ? min.

storage1

Lab Notes:


104




105



Unpublished Work of SUSE. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary, and trade secret information of SUSE. Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for SUSE products remains at the sole discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.


Documents

Install and Configure an Open Source Identity Server Lecture · 2014. 4. 23. · SUSE05 & 06: Configure an Open Source Identity Server & Secure Access to Linux Services Copying all