Overview

By nature UNIX and Windows worlds have never been friends. In my career as IT professional
companies have always made a distinction between both worlds having separated IT teams
specialized on each of those platforms. I would even dare to say there has been some historical
rivalries between both teams which made them to compete with each other. Those worlds
were taking their separate ways without caring about each other. However this has changed
since some years now with the consolidation of Linux as a competing enterprise platform with
Windows for depending what objective and also the consolidation of Linux initiatives like
Samba. Being quite honest we need to be thankful for that since now we can integrate both
Linux and Windows, or in other words make both platforms work together, reducing the
complexity of IT management and hence the TCO all managers over the worlds are always
looking after.

In a more pragmatic term,

after more than 13 years as a SAP technology expert, Linux and Windows integration
capabilities are a quite nice and interesting achievement since traditionally many companies
chose UNIX as platform for big SAP servers while having a Windows network for managing their
end-user desktop stock. I know what you are thinking. This assertion is more than discussable
nowadays and I fully agree Windows and UNIX can compete now as platform for SAP. However
many companies have inherited this philosophy from back those days, developed a wide know-
how over the time which are not willing to throw away in a blink of an eye and invested quite
nice amount of money already. Putting this altogether make them kind of reluctant to move
they SAP infrastructure from UNIX to Windows. This is therefore a scenario when companies
can benefit from having Linux and Windows working together. I can imagine for instance having
a Linux box as a gateway for key users to access from their Windows desktops a set of backend
UNIX servers they will be allow to all being centrally managed for Active Directory Services. I
believe this is really an awesome nice-to-have feature.
It will in addition help to minimize the impact and improve the control over the overall IT
security making your IT environment more secure. For instance it will be easier the split of the
overall company network in security zones, avoid having non-technical accounts in the backend
server or avoid passwords being transmitted in plain over the wired.

This is why I thought of writing this article and show you two choices you have out of there for
achieving Linux and Windows integration in two fields that are pretty much related:

1. Identity Management integration

2. File sharing integration

Do not forget either all this is achieved using free and open source software available out-of-
the-box in any enterprise Linux distribution available in the market which makes the cost
savings even more attractive and noticeable.

So eventually you will be able to reduce cost and improve your security making a relatively
small effort compared with the gains you will get. So I believe you will find worthy to spend a
few minutes of your valuable time reading the article all through.

Identity Management Integration

As the very first step to be able to integrate Linux and Windows, we need to make both
platforms to see and understand same identities. Or in other words, be able to centrally
manage identities. In both world identities are the very basis of security models (i.e. ownership
and permissions).

The first question you need to make yourself is who will store the central identity database.
Windows or Linux? I can then think of having Linux playing that role. For instance Linux offers
out-of-the-box the tools to create and set up both a Kerberos 5 and a LDAP server pretty much
emulating the functionality offered by Microsoft Active Directory Services. However I think it
makes much more sense to think of Windows as the identity provider using Microsoft Active
Directory Services. This is indeed the most common scenario nowadays and therefore the one I
am going to focus on.

Let’s move on then. Now how can you make Linux and Windows see same security identities?
Well the good thing is there are several solutions out there aimed at making this possible. You
have several commercial solutions like the ones offered by vendors like Centrify, Quest, FoxT or
BeyondTrust. However if your UNIX mates are skilled enough you can also go for free tools
included in most of the enterprise-class Linux distributions like Red Hat Enterprise Linux or
SUSE Enterprise Linux.

So let’s make your managers happy and explore the free options. Yes, I said options…plural.
Amazingly we have more than one free option. Nonetheless the two variants that I will be
focused on are:
 1. Winbind included in Samba suite
2. Well-known UNIX LDAP and Kerberos 5 tools

Let me at least quickly comment I did not mention anything about System Security Services
Daemon (SSSD). If you are an avid Linux follower you may think on SSSD as another free
alternative for achieving identity management integration between Linux and Windows. And
yes it is. It was indeed designed having this in mind. However I will leave SSSD for a new article
since this is something I need to test more in deep while I know those two other variants are
working ok in real environments.

Prerequisites
No matter which of the variants you picked, you have to first meet some requirements to be
able to start.

Of course the most essential one is you need to have at least Active Directory Services (ADS)
fully operative in your Windows network. Nothing to question and mention about it, don’t you?

Secondly you will need to extend the AD schema accordingly so that UNIX-related information
about your identities are stored somewhere within AD database. This might lead you to your
first headache since you could find restrictions in your company to do this. However this is also
a prerequisite to be met. Good thing about it is this is somehow standardized in  RFC 2307 by
Internet Engineering Task Force (IETF). Indeed Windows 2008 Server offers out-of-the-box the
possibility to extend AD schema with RFC 2307 compliant attributes by installing ADS
feature Identity Management for UNIX. Therefore in most of the cases this should not be a big
deal.

Third it is essential your ADS infrastructure and Linux boxes to be synchronized in time. This is
a must on any Kerberos environment for the security sake. Therefore make sure you have a
time server within your network and NTP properly setup in the Linux box.

And finally you need to store the right records in your DNS database so that the discovery
services work properly. This is done automatically by the wizard in charge of setting up your
ADS domains anyway. Further discussion in this area is fully out of the scope of this article. I
would rather suggest you to read this other one at Microsoft TechNet How DNS Support for
Active Directory Works. DNS queries executed by discovery services of many AD clients run
mostly behind the scene but it makes your installation more manageable, less error prone and
more robust on future changes.

Winbind
So that’s all with prerequisites. Let’s see now the first of the options.
What is Winbind then? Basically it is an UNIX daemon delivered as part of the Samba suite
which allows to extract identity information from Active Directory in the same way as any other
Windows domain member does. This is indeed the main advantage of Winbind. It resembles
Windows domain members making possible to join a Linux box into a Windows domain using
same native calls to ADS.

But what is really inside Winbind and which services does it implements? Fundamentally
Winbind delivers following Linux services:

1. A Name Service Switch (NSS) library

2. A Pluggable Authentication Module (PAM) module
3. UNIX-Windows identity mapping backends

The first of the services is, NSS, is a mechanism for name resolution within UNIX-like operating
systems due to the natural need of converting identifiers (better understood by computers) to
names (better understood by human beings). It allows to look up for information and resolve
names for different databases like users, groups, hosts, TCP/IP services, etc. In particular the
NSS library included with Winbind allows Linux boxes to read user and group accounts stored
in ADS as they were local ones.

The second of the services, PAM, is essential for the authentication part of the identity
management. PAM is the way Linux has to make both authentication and account management
transparent to the applications. In other words making an application PAM-aware allows you
for instance to switch from a password-based authentication to a fingerprint recognition one
without changing a line of code. Almost every application in Linux are PAM-aware nowadays
which makes very easy, quick and convenient the way you can adapt how Linux authenticates
users to your specific needs. In particular Winbind PAM module, pam_winbind, makes possible
to authenticate users against ADS domains.

And finally the third of the services, the identity mapping backends (IDMAP). How Windows and
UNIX identifies user accounts and user groups are radically different. While Windows uses the
concept of Security ID (SID), UNIX uses User Identifiers (UID) and Group Identifiers (GID). There is
then a need to map SID to UID and GID. Winbind offers different ways to achieve this mapping
by means of the so-called idmap backends. You have the possibility to use local databases
managed and maintained by Winbind, an algorithm that takes the so-called Relative ID (RID) as
an input, extract that information from a LDAP directory or even get them from AD itself. For
each backends you obviously have pros and cons. However since we are looking for an
enterprise class Linux-Windows integration, I highly recommend to go for the Active Directory
IDMAP backend (idmap_ad in Samba terminology) which will allows you to have a centralized
user management based on ADS. Nonetheless, as mentioned already in the prerequisite
section, it requires you to extend your AD schema with RFC 2307 compliant attributes.

Finally now that you know what Winbind is capable to do let me outline the overall
configuration steps I suggest to integrate a Linux box to your ADS domain. It is not my intention
though to go through a detailed one. The official Samba website at http://www.samba.org is
plenty of documentation if you like.

1. Install the Kerberos 5 client suite and set up the realm accordingly in /etc/krb5.conf. You
can either picked Heimdal and MIT However I am used to work with MIT to set up my
LAB.QOSIT.LOCAL realm:

?
[libdefaults]
    default_realm = LAB.QOSIT.LOCAL
    dns_lookup_realm = true
    dns_lookup_dns = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
 
[domain_realm]
    .lab.qosit.local = LAB.QOSIT.LOCAL
    lab.qosit.local = LAB.QOSIT.LOCAL

2. Install Samba Winbind suite and set up Winbind parameters within the file
/etc/samba/smb.conf. This is I would say the more complex step due to the multiple
parameters offered by Winbind. However essentially do not forget to:

a) Set up the NetBIOS server name

b) Set up the Windows domain name you want to join to

c) Set up the Kerberos 5 realm

d) Set up the Winbind IDMAP backend to idmap_ad

e) Set up the range of UID and GID idmap_ad is authoritative (in the example below I authorize
Winbind to handle accounts with uidNumber and gidNumber between 200000 to 299999 in my
LAB domain)

f) Set up the schema mode used by idmap_ad to rfc2307

g) Optionally you can cache credentials setting parameter “winbind offline logon” to yes

For instance:

?
[global]
netbios name = samba
server string = Samba server in lab
workgroup = LAB
realm = LAB.QOSIT.LOCAL
security = ads
idmap cache time = 60
idmap negative cache time = 60
idmap config * : backend = tdb
idmap config * : range = 100000-199999
idmap config LAB : backend = ad
idmap config LAB : default = yes
idmap config LAB : range = 200000-299999
idmap config LAB : schema_mode = rfc2307
winbind nss info = rfc2307
winbind enum users = yes
winbind enum groups = yes
winbind refresh tickets = yes
winbind normalize names = yes
winbind use default domain = yes
winbind nested groups = yes
winbind offline logon = yes
template homedir = /home/%D/%U
template shell = /bin/bash
encrypt passwords = yes
preferred master = no
max protocol = SMB2
unix charset = UTF8
printable = no
browseable = yes
writeable = yes
log level = 3

3. Join the Linux server to the AD domain by means of “net” command included within
Samba suite. This command will create a computer account into your AD directory.

?
# net ads join -S <domain controller> -U <admin> createcomputer=<AD
container>
# net ads testjoin
Join is OK

4. Add “winbind” as NSS provider for at least users and groups databases within
configuration file /etc/nssswitch.conf.

?
passwd:     files winbind
shadow:     files winbind
group:      files winbind

5. Adapt your PAM authentication stacks within directory /etc/pam.d so that module
pam_winbind is able to authenticate users against your AD domain controller. You can
also set fancy stuff within PAM like automatic creation of home directories if it does not
exist, or automatically get a TGT Kerberos ticket when logging in. For instance:

?
auth     required     pam_env.so
auth     sufficient   pam_unix.so try_first_pass
auth     sufficient   pam_winbind.so use_first_pass cached_login krb5_auth
auth     required     pam_deny.so
 
account required     pam_unix.so broken_shadow
account sufficient   pam_localuser.so
account sufficient   pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_winbind.so cached_login
account required     pam_permit.so
 
password requisite     pam_cracklib.so try_first_pass retry=3 type=
password sufficient   pam_unix.so sha512 shadow try_first_pass use_authtok
password sufficient   pam_winbind.so cached_login use_authtok
password required     pam_deny.so
 
session optional     pam_keyinit.so revoke
session optional     pam_winbind.so
session required     pam_limits.so
session optional     pam_mkhomedir.so umask=022
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session required     pam_unix.so

6. Maintain the RFC 2307 attributes in ADS for those Windows users and groups you want
to make visible in Linux (essentially uidNumber and gidNumber).

You will then have a Linux box able to recognize Windows users and groups. Cool isn’t it?

Kerberos 5 and LDAP Client Tools

Let’s first think for a moment what Active Directory Services (ADS) is from a more theoretical
perspective. Being very simplistic it essentially implements a Kerberos Key Distribution Center
(KDC) plus a LDAP directory server. Therefore using both Kerberos 5 and LDAP client tools we
should be able to interact with ADS as well.

As a theory it sounds great doesn’t it? But we all know theory is sometimes far from reality.
However lucky us this is not the case. So let’s go straight to the point now. Essentially the idea
behind this variant is nothing else than authenticate, authorize and map identities contained
within ADS as we did using Winbind above but this time using UNIX tools which essentially
implements well-known open standards like Kerberos 5 and LDAP instead.

First goal is authentication. I will use Kerberos 5 for authenticating identities which is eventually
the intend of Kerberos indeed. As I mentioned above you have two main implementations of
Kerberos 5 in UNIX, MIT or Heimdal, however I am used to work with MIT one so this is the one I
recommend you to use. Apart from this you also need to integrate Kerberos 5 within your PAM
authentication stack. For this you can use Kerberos 5 PAM authentication module pam_krb5.
Therefore to cover the authentication part I will use MIT Kerberos 5 client tools plus pam_krb5
module.
Second and third goals, authorization and identity mapping, go together. You know already the
way UNIX implements authorizations is based on user and group accounts identified by some
identifiers: UID and GID. This information can be extracted from attributes stored within the
ADS directory via LDAP queries which eventually will map a particular Windows user or group
account to a given UID or GID. This is in fact what nss-pam-ldapd does for you. It provides a NSS
daemon, nslcd, with many configuration options that allows any LDAP server (like ADS) to
provide user and group account information.

Note that fundamentally there is no difference with Winbind on how to map Windows and
Linux identities since both approaches achieve this by extending the AD schema with a set of
attributes. I suggest all across this article to be as much compliant as possible with RFC 2307
(which is a must in the case of Winbind anyhow). The difference basically is conceptually from
an UNIX administrator perspective. Using native LDAP client tools allows UNIX administrators to
define specific LDAP queries for extracting information from ADS which makes this approach to
adapt better to almost any scenario possible. Winbind on the other hand will abstract those let
´s says low level technical details making the overall setting procedure much easier.

So the overall configuration steps to integrate a Linux box into your Active Directory Domain
Services network using Kerberos and LDAP tools will be:

1. Install the Kerberos 5 client suite (MIT Kerberos 5 for instance) and set up the realm
accordingly in /etc/krb5.conf as shown above.

2. Install the openLDAP client and library tools.

3. Install nss-pam-ldapd package. NSS LDAP daemon nslcd will then be available and it can
be set up accordingly by filling file /etc/nslcd.conf. You must keep a careful eye on how
nslcd daemon will bind to your ADS as a LDAP server:

a) By default nslcd will bind anonymously. However this will need to be explicitly enabled in
your ADS infrastructure.

b) You can though use a specific AD account with enough rights to read attributes in the AD
branch containing the corresponding identities nslcd daemon is authoritative. This is known
as bind user account (see parameters binddn  and bindpw in example below).

c) As a more advanced and tricky option but also more secure variant of option “b”, you can
even set up nslcd daemon to bind to ADS as kerberized service. Here Cyrus SASL as a Simple
Authentical and Security Layer implementation (RFC 4422) will be of great help.

Apart from this, note you explicitly need to define in /etc/nslcd.conf the LDAP queries to be run
against your ADS to get entities within each of NSS database in scope (passwd, group and
shadow in the example below). This indeed makes this alternative kind of more tricky one but
at the same time however it adapts better to almost any scenario.
For instance:

?
uri dns
uid nslcd
gid ldap
ldap_version 3
ssl no
binddn CN=LDAP Bind User,OU=Users,OU=Samba,OU=Projects,DC=lab,DC=qosit,DC=local
bindpw <your password>
bind_timelimit 10
timelimit 10
base OU=Projects,DC=lab,DC=qosit,DC=local
scope sub
pagesize 1000
referrals off
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)
(unixHomeDirectory=*))
map    passwd uid               sAMAccountName
map    passwd homeDirectory     unixHomeDirectory
map    passwd gecos             displayName
filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)
(unixHomeDirectory=*))
map    shadow uid               sAMAccountName
map    shadow shadowLastChange  pwdLastSet
filter group  (&(objectClass=group)(gidNumber=*))
map    group  uniqueMember      member

4. Add “ldap” as NSS provider for at least users and groups databases within configuration
file /etc/nssswitch.conf.

?
passwd:     files ldap
shadow:     files ldap
group:     files ldap

5. Start up nslcd daemon. You will need also to add this daemon within your initialization
scripts for starting it up automatically upon reboots.

6. Install the Kerberos 5 PAM authentication module pam_krb5.

7. Adapt your PAM authentication stacks within directory /etc/pam.d so that module
pam_krb5 is able to authenticate users against your KDC implemented as part of your
ADS.

?
auth      required      pam_env.so
auth      sufficient    pam_unix.so try_first_pass
auth      sufficient    pam_krb5.so use_first_pass
auth      required      pam_deny.so
 
account   required      pam_unix.so broken_shadow
account   sufficient    pam_succeed_if.so uid < 500 quiet
account   sufficient    pam_krb5.so
account   required      pam_permit.so
 
password  requisite     pam_cracklib.so try_first_pass retry=3 type=
password  sufficient    pam_unix.so sha512 shadow try_first_pass use_authtok
password  sufficient    pam_krb5.so use_authtok
password  required      pam_deny.so
 
session   optional      pam_keyinit.so revoke
session   optional      pam_krb5.so
session   required      pam_limits.so
session   optional      pam_mkhomedir.so umask=022
session   [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session   required      pam_unix.so

8. Maintain in ADS the attributes for those Windows users and groups according to the
LDAP query you set up within the nss-pam-ldapd configuration file (/etc/nslcd.conf). I
have recommended across this article to be compliant with RFC 2307 standard as much
as possible but this is not strictly a must with this variant since in theory you can in fact
map any attribute by means of corresponding directives within /etc/nslcd.conf.

Now you can have a second way to integrate your Linux box with a Windows network. Don’t you
think this is cool yet?

Which one can I use?

Being quite frankly I don’t dare to give you a clear recommendation. I would say the final
decision should be made in a per scenario basis. However in my opinion Winbind variant is
more straight forward and easier to set up and it obviously integrates better with Samba since
it is part of the suite. It can be also consider as a Windows-like approach since it is eventually an
UNIX implementation of the SMB/CIFS protocol. Moreover it allows credentials caching for
offline logins which is a must on mobility scenarios. Besides using Kerberos 5 and LDAP client
tools makes Windows and Linux integration a UNIX-like approach so this is something maybe
your UNIX team will be happy of. Additionally I also think using Kerberos 5 and LDAP client tools
is more flexible and potentially adapts better to scenarios requiring special attributes
mappings. However it lacks the options for offline logins.

In any case, let me highlight the good and common points about both of them:

 They both are based on open source and free software included out-of-the-box within
most used enterprise level Linux distributions. So you won’t need to spend any extra
money to make it possible other than to make the effort to go for it and set it up.
 They both allows you to have a centralized user management based on ADS.
 They both allows you to use Single Sign-On in Samba when used as file and printing
server (coming next).
File Sharing Integration
Once you achieve identity integration between Linux and Windows as described in the previous
section, you can then make a step further and start serving and sharing files between your
Windows user community and Linux. Due to the fact users and groups are centrally managed
you don’t need to worry of maintaining permissions locally on each platform separately. Think
for instance having a Linux file server which a subset of your Windows user community (after
an explicit allowance to do so in ADS) can used as an entry point to access files to your UNIX
backend servers running your core business applications right from their Windows desktops
and without the need to create same local accounts over and over again in those UNIX backend
servers. This is of course very convenient in terms of security and maintainability.

But which is the easiest way to achieve this? In my opinion there is no question in this area: the
answer will be Samba. As mentioned already above Samba is an UNIX implementation of
the SMB/CIFS protocol widely used for instance by Windows networks. It started back in 1992
when Andrew Tridgell began to develop what is today a stable suite offering files and printing
services for SMB/CIFS clients being of course Windows among them. But this is not the only
feature which makes Samba so great. Samba is a free and open source software licensed under
the terms described by GNU General Public License.

But do I have an alternative to Samba? Yes you do. As a file sharing alternative you may think
for instance to have and install a NFS client for Windows. I have to admit I don’t have too much
experience in working with any NFS client implementations for Windows. I know there are some
options out there but never got the chance to test them. However, I did not have to bother on
doing so yet since Samba came to my rescue. And really why to bother while Samba gives me a
stable, easy and straight alternative to achieve this?

One more point in favor of Samba. It allows you to use either of the techniques I described
above to integrate identity management between Linux and Windows. This is indeed a key
factor and I would say the most tricky one. Once this integration is done, serving file services
with Samba is a matter to adding shares to the configuration file. Samba while serving files and
printing services to clients relies directly on the underlying OS authentication and authorization
facilities. On one hand Winbind will perfectly work together Samba file servers since it is part of
the Samba suite. It is in fact the most straightforward way to get identity and file sharing
integration altogether between Linux and Windows. On the other hand, Samba can also benefit
of the technique described in section Kerberos 5 and LDAP client tools above.

Apart from this, Samba implements the two security levels described in SMB/CIFS
protocol: user and share  security levels. Samba calls this as security modes and distinguish
between following ones: share, user, server, domain and ads. I won’t go in deep with this wide
Samba topic in here. I will refer you to the official Samba How-To though. However for an
enterprise class Linux and Windows integration my recommendation is to choose security
mode “ads” which will make your Samba box to behave as domain member server.
?
[global]
netbios name = samba
server string = Samba server in lab
workgroup = LAB
realm = LAB.QOSIT.LOCAL
security = ads
encrypt passwords = yes
preferred master = no
max protocol = SMB2
unix charset = UTF8
printable = no
browseable = yes
writeable = yes
log level = 3
You need to join your Samba box to the ADS domain though which means to create a computer
account in ADS as any other domain member. Lucky us Samba suite provides command net for
this. I showed already an example of using this command while setting up Winbind that is
required for Winbind to work. Note that however this is not the case while integrating your
Linux into ADS infrastructure as described in Kerberos 5 and LDAP client tools above. Therefore
do not forget to execute this step in this particular case otherwise you won’t be able to access
your Samba shares.

?
# net ads join -S <domain controller> -U <admin> createcomputer=<AD
container>
# net ads testjoin
Join is OK
Once the Samba server becomes an ADS domain member server it will in turn be in a position
to accept Kerberos tickets issued by your ADS infrastructure. Why is this so important? Well
because of two fundamental reasons: for security’s sake itself and for Single Sign-On that will
allow your Windows clients to access shares served by Samba without typing passwords over
and over again. Users of course have to be explicitly allowed to access a given set of shares in
Samba configuration (for instance by assigning a set of users to a given user group), but once
this is done and they successfully log in onto the AD domain, they will be able to access those
shares straight ahead by simply clicking on them.

For instance, let’s say we have a share “Documents” being served by Samba like this:

?
[Documents]
path = /samba-shares/documents
comment = Share for documents
valid users = @SambaGroup1
force group = SambaGroup1
Any AD user belonging to AD group “SambaGroup1” who successfully logged in onto the ADS
domain from his or her Windows PC will be allowed to read and write data on share \\<samba-
hostname>\Documents just without typing his or her password again.
But I still have one more point in favor of Samba yet. You do not need to deploy any extra
software packages like for instance NFS for Windows all across the whole Windows PC
community. Samba though will work out-o-the-box from a Windows user’s perspective. This is
really important in terms of maintainability and hence will help to reduce the overall TCO.

Therefore in summary you can use Samba as a kerberized file and printing server fully
integrated into your Windows network and compliant with your ADS-based central user
management. Comparing with NFS for instance, I don’t really think this is something so easy
and straightforward to achieve due basically to the nature of NFS as a file sharing protocol
borned and designed to work in UNIX environments.

Conclusion
I will feel happy at least if you after reading all through this article understand one simple
message: you can convert a Linux box into an enterprise class file and printing server fully
integrated into your ADS infrastructure as any other Windows network server using open
source and free tools. I really think this is as a solid, realistic, straightforward, helpful and cheap
option for companies requiring solutions for sharing information between both UNIX and
Windows worlds.