Sunteți pe pagina 1din 8

Linux Samba Server integration with Windows Active Directory – Part 1

Samba is an opensource suite that provided file and printer services in


a heterogeneous environment ( with Windows , Unix and Linux). The key advantage of
samba service is, it’s ability to provide file and print shares for both Windows and Unix
clients equally. My main focus of this post is how to configure samba services integrated
with Windows active directory services, so that samba user authentication will be
performed by Windows Active Directory Services.

To understand the Samba configuration to integrate with Windows ADS, we need to understand
below fundamental concepts

Kerberos Authentication:
Kerberos is a trusted third-party authentication service, keeps a database of its clients and
their private keys. The private key is a large number known only to Kerberos and the client
it belongs to.In Kerberos, both users and servers are named. As far as the authentication
server is concerned, they are equivalent. A name consists of a primary name, an instance,
and a realm, expressed as name.instance@realm.
Linux winbind Service:
Winbind unifies UNIX and Windows account management by allowing a UNIX box to
become a full member of a Windows domain. The service provided by winbind daemon, is
called winbind and can be used to resolve user and group information from a Windows
Domain Controller, which makes it understandable by UNIX platforms. The service can also
provide authentication services via an associated PAM module. The pam_winbind module
supports the auth, account and password module-types. The winbind service is provided
by samba-common package, as a component of samba.
In this first part of the samba configuration, I am presenting a quick overview of
Kerberos authentication , and Linux configuration as a Kerberos client. And also
demonstrating the procedure to add the Linux Samba server to windows domain using the
winbind.

Quick Overview of Kerberoes Authentication


There are two types of credentials used in the Kerberos authentication model:
 Tickets : A ticket is used to securely pass the identity of the person to whom the ticket
was issued between the authentication server and the end server.
The authenticator contains the additional information which, when compared against
that in the ticket proves that the client presenting the ticket is the same one to which the
ticket was issued. A ticket is good for a single server and a single client. It contains the
name of the server, the name of the client, the Internet address of the client, a
timestamp, a lifetime, and a random session key.
 Authenticators : Unlike the ticket, the authenticator can only be used once. A new one
must be generated each time a client wants to use a service. This does not present a
problem because the client is able to build the authenticator itself. An authenticator
contains the name of the client, the workstation’s IP address, and the current
workstation time
Both are based on private key encryption, but they are encrypted using different keys .

The Overall Kerberos Authentication in 3


phases :
Step 1: Client Requests Initial Kerberoes Ticket to Access the Ticket Granting Server
When the user walks up to a workstation.The user is prompted for her/his username. Once
it has been entered, a request is sent to the authentication server containing the user’s name
and the name of a special service known as the ticket-granting service.
The authentication server checks that it knows about the client. If so, it generates a
random session key which will later be used between the client and the ticket-granting
server.
It then creates a ticket for the ticket-granting server which contains the client’s name, the
name of the ticket-granting server, the current time, a lifetime for the ticket, the client’s IP
address, and the random session key just created.
The authentication server then sends the ticket( TKT-1 ), along with a copy of the random
session key ( SK-1) and some additional information, back to the client

Step 2: Client Requests to Ticket Granting Server, for a ticket to access Samba Server

The Client creates a Authenticator (AUTH1) using the session key (SK1) and ticket (TKT-
1) received in the first step. The Client Send this authenticator, along with the ticket (TKT)
to Ticket Granting Server.

Ticket Granting Server validates Authenticator and generates new tickets ( TKT-2) session
key ( SK-2) for the client and samba server to use.
Step 3: Client Access to the Samba Server
The Client uses the recently received Session Key (SK-2) to create new Authenticator ( Auth-
2) . And Then Client Sends both Session Key ( SK-2) and Authenticator ( AUTH-2)
to the samba server. The Samba server validates both Authenticator and Session Key, and if
all matches it authenticate client Connection.
In addition to authenticating client connection, the samba server sends a new session Key
( SK-3) encrypted with new time-stamp, and returns the Session key to Client.
Client Validates the new session key ( SK-3) and confirms that it is is communicating with
the right server. Then the connection establishes between client and the Samba server.

Linux Configuration as Kerberos Client


My Lab Setup:

OS Versions : Windows 2003 Server ( IP Address : 10.200.202.44) , Redhat


Enterprise Linux 6.1 ( IP address: 10.200.202.91)
Windows Domain : GURUKULINDIA.COM
WINDOWS SERVER : GURKULADS.GURKULINDIA.COM
Linux SAMBA SERVER : Ramdev-test-1.Gurkulindia.com
Note 1 : DNS configured on Windows ADS Server.
>> edit /etc/resolv.conf and make following entries

nameserver 10.200.202.84

search gurkulindia.com

Note 2 : To keep the system time in sync, I have configured WINDOWS 2003 SERVER to use
local system clock and configured Linux to refer the Windows as NTP server.
>> Comment out current NTP servers, and add the Server Entry referring to Windows Server.
example Below

[root@ramdev-test-1 samba-demo]# vi /etc/ntp.confserver


server 10.200.202.84
[root@ramdev-test-1 samba-demo]# service ntpd stop
[root@ramdev-test-1 samba-demo]# service ntpd restart
remote refid st t when poll reach delay offset jitter
==================================================================
============
gurkulads.gurk .LOCL. 1 u 3 64 1 1.083 -13.057 0.000
[root@ramdev-test-1 samba-demo]# chkconfig ntpd on
[root@ramdev-test-1 samba-demo]# chkconfig -l-list ntpd
ntpd 0:off1:off2:on3:on4:on5:on6:off

Install Kerberos Packages if not installed already:

[root@ramdev-test-1 samba-demo]# yum list installed|grep krb5


krb5-devel.x86_64 1.9-33.el6_3.3 @ol6_latest
krb5-libs.x86_64 1.9-33.el6_3.3 @ol6_latest
krb5-pkinit-openssl.x86_64 1.9-33.el6_3.3 @ol6_latest
krb5-server.x86_64 1.9-33.el6_3.3 @ol6_latest
krb5-server-ldap.x86_64 1.9-33.el6_3.3 @ol6_latest
krb5-workstation.x86_64 1.9-33.el6_3.3 @ol6_latest
pam_krb5.x86_64 2.3.11-6.el6 @anaconda-RedHatEnterpriseLinux-
201105101844.x86_64/6.1
[root@ramdev-test-1 samba-demo]# yum -y install krb5-workstation
Loaded plugins: product-id, refresh-packagekit, subscription-
manager
Updating Red Hat repositories.
Setting up Install Process
Package krb5-workstation-1.9-33.el6_3.3.x86_64 already installed
and latest version
Nothing to do
[root@ramdev-test-1 samba-demo]# cp /etc/-p /etc/krb5.conf
/etc/krb5.conf.orig

Modify /etc/krb5.conf to refer to Windows ADS server as Kerberoes Authentication Server. Under
the Kerberos, [realms] is set to the kerberos server definitions and [domain_realm] defines the
active directory server.Both are in gurkulindia.com. Below will show the file before and after the
change

[root@ramdev-test-1 samba-demo]# sdiff /etc/krb5.conf


/etc/krb5.conf.orig
[logging] [loggi
ng]
default =
FILE:/var/log/krb5libs.log default =
FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log kdc =
FILE:/var/log/krb5kdc.log
admin_server =
FILE:/var/log/kadmind.log admin_server =
FILE:/var/log/kadmind.log
[libdefaults] [libd
efaults]
default_realm
= gurkulindia.com | default_realm =
EXAMPLE.COM
dns_lookup_realm = true | dns_lookup_realm =
false
dns_lookup_kdc = true | dns_lookup_kdc = false
ticket_lifetime =
24h ticket_lifetime = 24h
renew_lifetime =
7d renew_lifetime = 7d
forwardable = false | forwardable = true
[realms] [rea
lms]
gurkulindia.com =
{ | EXAMPLE.COM = {
kdc = gurkulads.gurkulindia.com | kdc =
kerberos.example.com
admin_server
= gurkulads.gurkulindia.com | admin_server =
kerberos.example.com
} }
[domain_realm] [dom
ain_realm]
.gurkulindia.com
= GURKULINDIA.COM | .example.com =
EXAMPLE.COM
gurkulidnia.com
= GURKULINDIA.COM | example.com =
EXAMPLE.COM

Just to make sure that we have no expired tickets and cleanup if any existing tickets just run below
kerberos commands

[root@ramdev-test-1 samba-demo]# kdestroy <== to destroy any existing


tickets
kdestroy: No credentials cache found while destroying cache
[root@ramdev-test-1 samba-demo]# klist <== to list any existing
tickets
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_0)
[root@ramdev-test-1 samba-demo]# kinit
kinit: Client not found in Kerberos database while getting initial
credentials
<== kninit to obtain and cache Kerberos ticket-granting tickets, but it failed
because of no initial authentication
Obtain new Kerberos Ticket by authenticating to the Kerberos authentication server ( Windows
Domain Server) :

[root@ramdev-test-1 samba-demo]# kinit


administrator@gurkulindia.com
Password for administrator@gurkulindia.com:
kinit: KDC reply did not match expectations while getting initial
credentials <<= Command Failed. And the reason is, i have mentioned the domain
name in lower case. Next command with uppercase domain name is successfule
[root@ramdev-test-1 samba-demo]#
kinit administrator@GURKULINDIA.COM
Password for
administrator@GURKULINDIA.COM: <== command
success and the prompt returned
#
[root@ramdev-test-1 samba-demo]#
klist <== check the ticket-granting tickets
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@GURKULINDIA.COM
Valid starting Expires Service principal
10/11/12 12:14:04 10/11/12 22:14:08
krbtgt/GURKULINDIA.COM@GURKULINDIA.COM
renew until 10/18/12 12:14:04

That Concludes the Kerberos Authentication part. I will be posting continuation post about Samba
configuration procedure, joining Linux server to Windows domain using winbind and testing the
samba setup.