Mod 5

SAMBA AND AD

Secure Communication

Privacy
only the sender and the receiver should be able to understand the

conversation
Eavesdroppers can make no sense of information

Integrity
the receiving end must be able to know for sure that the message he is

receiving is exactly the one that the transmitting end sent

malicious user cant intercept a communication with the intent of modifying its
contents even without understanding the contents

Authentication
ensure that the parties involved in the communication are who they claim to

be
Impersonation

Authorization is not Authentication

Users can only access resources allowed

Prevent a valid user from hacking
Inside the system usually not part of communication

SECURITY IN
WINDOWS

SSO

Single Sign-On
the ability of a user to authenticate and

thereafter to have access to all authorized

network resources without additional
authentication

NTLM

Network Logon Security mechanism

A challenge/response authentication protocol
Used in NT systems and Windows versions below 2000 in
native mode or
The client is authenticating to a server that belongs to a different

Active Directory forest, or doesn't belong to a domain.

No Active Directory domain exists (commonly referred to as
"workgroup" or "peer-to-peer").
Where a firewall would otherwise restrict the ports required by
Kerberos

Kerberos
Authentication

Remember that Authentication and

Authorization are two separate
processes
It is an open standard (RFC 4120)
Kerberos is an Authentication protocol
which features mutual authentication or
shared secrets
Kerberos Version 5 is standard on all
versions of Windows 2000 and up

Kerberos Components

Key Distribution Centre (KDC)

Installed as part of DC
Provides two services
Authentication Service (AS)
Ticket-Granting Service (TGS)

The client

The server with the resource

Must be able to accept and process tickets

KDC
AS
TGS

DC

Kerberos Exchanges

AS Exchange (Authentication
Service)
Authenticate on the domain
AS-Request and AS-Reply

TGS Exchange (Ticket Granting

Service)
Get a ticket to access a resource
TGS-Request and TGS-Reply

CS Exchange (Client/Server)
Access the resource

User Keys (shared

secret)

When a user is created, the password is

used to create the user key.
In Active Directory domains, the user
key is stored with the user's object in the
Active Directory.
At the workstation, the user key is
created when the user logs on.

First we have to find a

DC
1.

2.

3.

4.

The user enters username,

password and domain
information into the logon dialog
box.
The logon credentials are
passed to the local security
subsystem on the workstation.
The local security subsystem
on the workstation checks the
domain name entered in the
logon credentials and queries
DNS to find a Domain controller
for the domain. (DNS SRV
record)
The DNS server must provide
the address of a Domain
controller which will also have
Kerberos services (KDC)

Then we create our secret key

5.

The Kerberos client on

the workstation creates
the users secret key

6.

The users timestamp is

encrypted with the users
password to form the
users secret key (USK)

The users secret

encrypted key (USK) is
saved in the
workstation's credential
cache.

The AS-Exchange (AS-Request)

7.
8.

The KDC Authentication Service (AS) checks for the principal in the Active Directory
Database and global memberships in the global catalogue server.
If the principal is found and the key accepted, the AS service on the KDC creates a
Ticket-granting-ticket (TGT). The TGT has an expiration time (usually about 8hrs). The
TGT is sent to the workstation.

Pre-Authentication

By default windows uses

Kerberos pre-authentication
PA-ENC-TIMESTAMP
Password and timestamp

encrypted into a hash

This prevents user spoofing

The pre-authentication
feature may be disabled for
specific users in order to
support some applications
that don't support the security
feature

The AS-Exchange (ASReply)

9.

The TGT (Ticket Granting Ticket) is sent to the local security subsystem on the Client
workstation. The TGT is stored in the credentials cache with the USK. Together these form the
authentication information that the workstation will use to communicate with the KDC from
now on until the user logs out or the ticket expires.

TGT

This ticket can be used to request access to a domain resource such as a shared
folder or printer, or the ability to log on to a particular computer
has a default lifetime of 10 hours

may be renewed throughout the user's log-on session without requiring the user to re-enter his password.

The TGT is cached on the local machine in volatile memory space and used to
request sessions with services throughout the network

Time!!!!!

Maximum Tolerance For Computer Clock Synchronization: The Maximum tolerance for computer
clock synchronization is one of the few Kerberos policies that may need to be changed. By default,
computers in the domain must be synchronized within five minutes of each other. If the client clock and
the server clock are not synchronized closely enough, a client ticket is not issued. The default value is 5
minutes, and settings are in minutes. If there are remote users that log on to the domain without
synchronizing their clock to the network timeserver, it may be necessary to adjust this value.

The Ticket Granting

Service
A TGT and a Service Ticket are needed to
access resources on the domain
We have an TGT from the AS
(Authentication Service) exchange
We get a Service Ticket from the TGSExchange
When we are logging on we are asking for
access to the local machine which is a
domain resource so we need a Service
Ticket

The TGS Exchange (TGS-Request)

10. The client contacts the TGS wishing to
connect to a file share on the domain.
1.
2.
3.

The name of the target computer,

The name of the target computers
domain
The TGT.

11. The TGS decrypts the TGT, verifies

the user with Active directory and checks
the timestamp and the domain policies and
group membership.

The TGS Exchange (TGS-Reply)

12. If everything checks out the TGS
creates a TGS Reply (service ticket) and
returns it to the Client System to be
placed in the credentials cache.

Using the Service Ticket

13. The client can now contact the file
server with the desired share and present
the Service ticket.
14. The file server will check its Access
Control lists against the users name and
group membership and allow (or not) the
user access to the file system.

Summary

AS exchange occurs at logon, providing the client with

a TGT (Ticket Granting Ticket)
The TGT allows the client to enter the TGS exchange
(which authenticates the client), returning an ST
(service ticket)
The ST identifies the authenticated client to a service
following which the service will provide access (but only
if the client passes the services own authorization
criteria).
Because messages are encrypted, only the KDC can
read the TGT and only the service can read the ST.

Understanding Kerberos
Resources

http://www.youtube.com/watch?v=kp5d8Yv3-0c

http://www.youtube.com/watch?v=KD2Q-2ToloE&fe
ature=related
http://www.computerworld.com/computerworld/reco
rds/images/pdf/kerberos_chart.pdf

http://software.intel.com/sites/manageability/A
MT_Implementation_and_Reference_Guide/default.h
tm?turl=WordDocuments%2Fintroductiontokerberosa
uthentication.htm

CMPS305

SAMBA AND ADS

ADS Level Security

ADS Security Mode

In Samba you can join as a native AD member
All your machines are running Windows 2000 and above

and all use Kerberos

Worksta tion

SAMBA

Worksta tio n

Worksta tio n

Workstation

Windows
DC

Joining an active directory

domain

find a ADS DC
create a secret key
get krb5 TGT for administrator
Get Service ticket to join to domain
Complete join

SAMBA and ADS

First you have to load the Kerberos

workstation software
Allows samba to authenticate to a Kerberos server
Allows samba to get and use tickets
Allows samba to be seen as a principal

What would SAMBA need to be an Active directory domain

controller?

Configure the smb.conf file

Type of security
The kerberos realm
The password server

Configure the krb5.conf file

Smb.conf
A Kerberos Realm is
the a set of principles
administrated as a
single group in
Kerberos
All Windows domains
are also Kerberos
realms but the realm
name is always all
uppercase

Krb5.conf

Libdefaults sets the

deraults for Kerberos on
your system
Ticket lifetime
Realm

Realms where to find

KDCs for each realm
Domain_realm maps
the hostnames to
Kerberos realm
. = all
So all hosts in condm.com

map to condm.com realm

DNS

How does a domain member find a domain

controller?
DNS SRV records
So you have to know where to find a DNS server

And you have to make sure you have a proper hosts file

Testing it out

Kinit key
initialization for
administrator in
the domain
Klist get a list
of Kerberos
keys

Join the domain

Users

OK so we have some user issues to deal with

UID
GID
Shell

One way is to add them to the Linux passwd file and

then the smbpasswd file but thats too much work

Winbind
Unifies Unix and Windows account management
Pulls the windows usernames from the dc and integrates them into the

Linux /etc/passwd /etc/groups sysem.

Allows Unix to see and use the windows accounts
Listens for requests from NSS or PAM
Configure user mapping in the smb.conf

Must be started after smb and nmb

NSS

Nsswitch
Name Service Switch
Allows you to resolve names between services
is used by various functions in the C library to

control where information was looked for

/etc/nsswitch.conf, specifies the sources for the
``databases'' and their lookup order

The checkout

getent passwd