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:
- Identity Management integration
- 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:
- Winbind included in Samba suite
- 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.
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.
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:
- A Name Service Switch (NSS) library
- A Pluggable Authentication Module (PAM) module
- 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.
- 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
- 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
[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
- 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
- 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
- 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
- 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:
- Install the Kerberos 5 client suite (MIT Kerberos 5 for instance) and set up the realm accordingly in /etc/krb5.conf as shown above.
- Install the openLDAP client and library tools.
- 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.
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
- 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
- Start up nslcd daemon. You will need also to add this daemon within your initialization scripts for starting it up automatically upon reboots.
- Install the Kerberos 5 PAM authentication module pam_krb5.
- 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
- 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.
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.