Recent Changes - Search:
NTLUG

Linux is free.
Life is good.

Linux Training
10am on Meeting Days!

1825 Monetary Lane Suite #104 Carrollton, TX

Do a presentation at NTLUG.

What is the Linux Installation Project?

Real companies using Linux!

Not just for business anymore.

Providing ready to run platforms on Linux

Single Sign On

Setting up automatic authentication to Linux/Unix hosts from a Windows client.

Christopher J. Cox
North Texas Linux Users Group
May 20, 2006

Linux Is As Linux Does

Throughout this presentation, I will use the word Linux to mean a full Linux distribution with all of the GNU and NON-GNU software that often comes with a Linux distribution or at least is easily added as free software.

The term GNU/Linux is simply no longer sufficient to cover everything since there are free sources of software under BSD, MIT and other licenses. While some licenses are easily encompassed by GNU, others are not.

Domain Expectations

Questions?

  • I have to remember ANOTHER password?
  • I'm already logged in. Why doesn't it KNOW me?
  • How many accounts am I going to have to MANAGE?

Single Sign On

Single Sign On - The ability to authenticate one time for access to many resources.

  • Unix Lightweight Directory Access Protocol (LDAP)
  • Windows Active Directory (AD)
  • Samba and Winbind
  • Network Information Service (NIS)

All promise WAYS of achieving Single Sign On, but actual implementations are rare or limited to very homogeneous network environments.

Simple Single Sign On

SSH is an easy way to create Single Sign On.

 
user@myhost:~> ssh-keygen -t rsa -b 1024
user@myhost:~> ssh foreignhost "cat >>.ssh/authorized_keys2" <~/.ssh/id_rsa.pub
Password: <password>
user@myhost:-> ssh foreignhost
user@foreignhost:~>
 

SSH for Windows

SSH for Windows

PuTTY Simple Single Sign On

  • Download and install PuTTY.
  • Generate an SSH key with puttygen.
  • Copy and append OpenSSH key to .ssh/authorized_keys2 on foreignhost.

We're Done (???)

Simple as that... BUT...

  • Assumes Unix/Linux usernames exist already.
  • There are probably two separate account AND password databases.
  • May require lots of repetition.

Can we do better?

Linux/Unix Domains

  • Network Information Service (NIS) - Simple easy way to take an /etc/passwd database and make it work across a network.
    • Limited scalability (< 5000 users).
    • Allows capturing of encrypted DES passwords (brute force attack).
  • LDAP - Complex generic directory/database tool that can house account information.
    • Lots of schemas, differences of opinion on interpretation of schema data.
    • Can actually be slower than NIS on small installations.
    • Requires expert knowledge when things don't go right.
    • BUT... it is known to be VERY scalable.

Samba to the Rescue?

Samba - Brings SMB protocols (file/print sharing) to Linux/Unix AND the promise of full Windows Domain support.

  • Can act as an NT4 style Domain Controller (5/14/2006).
  • In some cases, can integrate with an existing set of Windows Domains, but very limited.
  • Pretty good support for allowing Linux/Unix machines to join a Windows Domain and enumeration of users/groups on that Domain.

Quandary

Windows is NOT about integration.

  • Windows cannot easily use an LDAP or NIS from Unix/Linux.
  • HOWEVER, Windows does not mind owning LDAP or NIS (NIS from the free SFU for Windows).
  • Samba Domains are NT4 style and don't work well with newer version of Windows.

It is easy to get Windows to not own DNS and DHCP, but very difficult for it to not own the username database. Therefore, in a mixed network, Windows gets to own at least the username database portion.

Winbind

Samba has a feature called Winbind that allows users from a Windows Domain to become available transparently on a Linux/Unix host.

  • There is not a one-to-one mapping of concepts.
  • A lot of account control is left to the Windows Domain.
  • Better at making Linux/Unix into a Windows-like server (a file/print server).

Winbind works well but leaves the Linux/Unix server in a subservient role. Primarily designed for situations where Linux/Unix boxes are to be value added servers in a Windows network.

Sometimes You Need Two

A balance is to use both Windows Domains based user accounts AND NIS/LDAP accounts with some kind of synchronization.

  • Creation of a new Windows Domain user could trigger a NIS or LDAP add somehow.
  • Password authentication could be done to the Windows Domain controller.
  • Accounting limits could still be done using just NIS/LDAP across just the Linux/Unix hosts.
  • Possible to have just WINDOWS accounts or just LINUX/UNIX accounts or SHARED accounts.

Solution Overview

The balanced approach:

  • DNS/DHCP owned by Linux. Windows DHCP support does NOT handle non-Windows hosts very well.
  • Windows Domain owned by Windows, Windows only and shared account creations. Eliminates incompatibilities in the pure Windows-to-Windows world.
  • NIS/LDAP Linux/Unix domain owned by Linux.
  • Shared (Windows/Linux/Unix) home directories owned by Linux. Exported via NFS and Samba. Samba becomes the triggering mechanism for NIS/LDAP account additions.

What Happened to Unix?

Linux simply does a much, much better job in supporting the protocols and subsystems used than commercial Unix. It is a much better integration platform and therefore better suited than Unix to handle enterprise level infrastructure pieces.

You could use Unix, but it would take much, much longer to make it functional.

Overview Diagram

Click to edit the image Click to edit the image Click to edit the image Click to edit the image

Not Covered Here

Time does not permit adequate treatment of the setting up of DNS/DHCP (with dynamic DNS) and basic NIS/NFS concepts.

NFS Home Directories and NIS

For normal Linux/Unix logins, create a centralized NFS exported home directory on fbcproxy, our NIS master.

  • /etc/exports
    /export/nfshome *(rw,root_squash,sync,insecure)
  • /etc/auto.master (pushed via NIS)
    /home auto.home
  • /etc/auto.home (pushed via NIS)
    nfshome fbcproxy:/export/nfshome
  • /etc/passwd (pushed via NIS)
    juser:x:5000:100:Joe User:/home/nfshome/juser:/bin/bash

Initial Global Samba Config

The winbind trusted domains only and winbind use default domain will allow the mapping of users of the form THEENDLESSNOW\JUSER to the juser in NIS.

 [global]
         workgroup = THEENDLESSHOME
         server string = FBC Proxy and Home Directory Server
         security = DOMAIN
         map to guest = Bad User
         realm = theendlesshome.com
         winbind trusted domains only = yes
         winbind use default domain = yes
         password server = *
         username map = /etc/samba/smbusers
         log level = 5

Initial Samba Homes Config

This will allow the THEENDLESSHOME\JUSER to see their shared home directory from our Linux Samba host.

 [homes]
         comment = Home Directories
         valid users = %S
         browseable = No
         read only = No
         inherit acls = Yes

Joining the Windows Domain

Ideally, any Linux/Unix box that needs to know about the Windows Domain, needs to be joined to it. Our Windows 2003 Server is called w2k3.

 $ net ads join -S w2k3 -U Administrator
 Using short domain name -- THEENDLESSHOME
 Joined 'FBCPROXY' to realm 'THEENDLESSHOME.COM'

Test the join by trying to retrieve the users from w2k3.

 $ net user -U Administrator
 Administrator's password:
 Administrator
 Guest
 ... etc ...

Using your Windows Password Instead

The Samba config so far would allow us to get to our shared home directory from Windows, but we can allow direct logins using our Windows password from w2k3 instead using the Linux/Unix NIS one (assuming we don't use SSH key'd access).

Install pam-smb (http://www.csn.ul.ie/~airlied/pam_smb/) onto fbcproxy.

  • /etc/pam_smb.conf
    THEENDLESSHOME,W2K3,W2K3

Then you must start up the /usr/sbin/pam_smbd daemon:

 # /etc/init.d/pamsmbd start

Configuring PAM to Allow Windows Auth

On SUSE, we will place our pam_smb change into the /etc/pam.d/common_auth file which is included in many services files to determine authentication.

 auth    required        pam_env.so
 auth    sufficient      pam_unix2.so
 auth    required        pam_smb_auth.so debug cachetime=20 use_first_pass

You should now be able to login as juser using either the NIS password or the Windows password.

NIS Insecurity

As mentioned earlier, NIS is insecure in that the DES encrypted password strings are easily retrieved for brute force password cracking attempts. While we could prevent the use of NIS passwords on a host and just use pam_smb, we probably want to allow for the JUST NIS case where a user is not know by the Windows Domain Controller (w2k3).

So instead, we'll simply changed the DES string to something that would be hard or impossible to enter. For simplicity, we'll use the DES string of OkBadPassword for our shared Windows/Unix/Linux accounts. However, I have no idea what password might actually hash to that DES value. More work needed on this.

Creating NIS Users Automatically

Assuming that we use our Samba home directory has our Windows home directory, when a user logs into the Windows Domain on a Windows XP host (for example), their home directory will get mapped to a drive letter. Samba has a global setting that can be used to perform an action when an unknown user attempts to access a resource. On fbcproxy add this extra line to the global parameters:

  add user script = /usr/local/sbin/nis_add_user %u %I

Now we simply need to create our nis_add_user program to add the user automatically.

NIS Add User Script

 username="$1"
 ip="$2"
 pid=$$
 logger -p auth.warning -t nis_add_user "IP [$ip] requested add user [$username]"
 rm -f /tmp/nis_add_user.$pid
 useradd -m "$username" &&
        echo "${username}:OkBadPassword" >/tmp/nis_add_user.$pid &&
        chpasswd -c des -e /tmp/nis_add_user.$pid &&
        usermod -d /home/nfshome/${username} ${username} &&
        (cd /var/yp;make)
 rc=$?
 logger -p auth.warning -t nis_add_user "IP [$ip] added user [$username]"
 rm -f /tmp/nis_add_user.$pid
 exit $?

Test Add New User

  • Add a new Windows user.
  • Set the user's home directory to our Samba/NFS home dir area.
  • Login from a Windows XP client on the Domain.

Test NIS Login

  • Use PuTTY to login to Linux/Unix host.
  • Home directory is automounted.

PuTTY Simple Single Sign On

  • Download and install PuTTY.
  • Generate an SSH key with puttygen.
  • Copy and append OpenSSH key to .ssh/authorized_keys2 on foreignhost.
  • And... save a copy of the PRIVATE key on your host, OR on your home directory.

PuTTY Pageant Startup Using Key

  • Save or shortcut your private key to your Startup folder.
  • Make sure you are using SSH2 and that your private key is adequately protected.

Done?

Some issues/limitations:

  • ONE Windows Domain per ONE NIS Domain.
  • Potential private key issues.
  • NIS still used.
  • NFS used.
  • Removal of users is somewhat limited.
  • Creation of users is somewhat inflexible.

Demo and Questions

Page last modified on April 25, 2012, at 08:49 PM