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

Overview

Seems that everyone is talking about Single Sign On solutions. Many of the proposed solutions center around LDAP. However, most either take the approach of competing directly against Windows Active Directory, or supplanting it. Some do some sort of cooperation with it but insist on replication. Lightweight Directory Access Protocol (LDAP) is known to be very scalable, and while LDAP syntax is well understood, the schema are generally a mystery and subject to much interpretation across platform LDAP solutions especially in the area of password control.

However, most companies do not require a solution that will scale into the tens of thousands of users. Most companies can live with solutions that scale into the low thousands. Network Information Service is a much simpler protocol that can derive information from the configuration on an existing host (the NIS master) instead of creating a separately managed name space for users and other network configuration data. NIS is formally known as Yellow Pages and is a simpler way of creating shared name spaces within a network for usernames, groups, mountable shares and more.

However, before we can jump right into joining Windows Active Directory and Unix/Linux NIS, we must consider the overall infrastructure.

Overview Diagram

TBD

The Players

fbcproxy

This Linux (SUSE 10) host will house our DNS/DHCP services as well as acting as our NIS master and the location of shared home directories (NFS/Samba). Unlike most Windows networks, it is not unusual to run a plethora of services on the same host in Linux.

fbcproxy - IBM Thinkcentre

Intel Pentium 4 2.8GHz (512KB), 533MHz FSB, 256MB, 40GB 7200RPM IDE HDD, PCI Small Form Factor (2x3), Intel 865G, DVD-ROM

 IP: 192.168.44.6 (eth0)
 Device: eth0 (internal, Intel onboard 82562EZ)
         eth1 (optional external internet, 3Com 3C905B)
         modem0 (optional external internet, Sanyo USB Cell Phone)
 OS: SUSE 10.0
 FQDN: fbcproxy.theendlesshome.com
 BIND Zones: theendlesshome.com, 44.168.192.in-addr.arpa
 DCHP Pools: 192.168.44.100 - 192.168.44.200
 NIS Master: fbc.nis
 W2K3 Domain: theendlesshome.com

This machine will also server as the gateway/firewall to the internet. It's internet facing address is determined dynamically and can either come dhcp on the eth1 interface, or via USB modem (mobile phone... for traveling road shows).

w2k3

This host is running a copy of Windows 2003 Small Business Server with 25 CALs. It will be using the fbcproxy as its gateway (if needed) and DNS. New users we add to the network will be added here. When needed, this host will be used for password authentication across the network.

w2k3 - Cappuccino G1

Intel PIII 1Ghz, 256MB, 60GB, DVD-ROM, Ultra Small Form Factor (roughly 6in x 6in).

 IP: 192.168.44.33 (eth0)
 Device: eth0 (internal, RealTek)
 OS: Windows 2003 Server SBS
 FQDN: w2k3.theendlesshome.com
 W2K3 Domain: theendlesshome.com Domain Controller

wiht

This Linux (SUSE 9.3-64bit) box is a client which also will run a couple of additional virtual machines using VMware. Users can login using SSH key, NIS password (when available) or Windows password.

wiht - Sun w2100z

Dual Opteron 246, 2GB, 2x73GB, 800G external RAID, 6600GT, 2xDVD-RW

 IP: 192.168.44.77 (eth0)
 Device: eth0 (internal, Broadcomm)
 OS: SUSE 9.3-64bit
 FQDN: wiht.theendlesshome.com
 NIS Client: fbc.nis
 PAM SMB: THEENDLESSHOME,W2K3,W2K3
 W2K3 Domain: theendlesshome.com

ntlugvp-xp

This is a Windows XP virtual machine joined to the Windows domain and active directory realm of THEENDLESSHOME. This guest OS is hosted on wiht. Demonstrates Windows logins and PuTTY key'd access to client Unix/Linux hosts.

ntlugvp-xp - VMware Guest OS on wiht

Virtual Machine, 128MB

 IP: DHCP from fbcproxy
 OS: Windows XP SP2
 FQDN: ntlug-vp.theendlesshome.com
 W2K3 Domain: theendlesshome.com

sol10

This is a Solaris 10 virtual machine which is part of NIS, but is NOT joined to the Windows domain. By default, logins would be done via key'd SSH.

sol10 - VMware Guest OS on wiht

Virtual Machine, 512MB

 IP: DHCP from fbcproxy
 OS: Solaris 10
 FQDN: sol10.theendlesshome.com
 NIS Client: fbc.nis

razor

This is the 2006 NTLUG Linux Fair giveaway box. It is a client as well and is similar to wiht in that it uses both NIS and is a member of the Windows Domain. Like wiht, it contains several VMware guest OS's, including Ubuntu 5.10, Fedora Core 5 and Windows XP.

razor - AMD 3700+

DFI LanParty NF4 SLI-DR, 3700+, 2GB, 36GB Raptor, 80G WD, 7800GT, DVD-RW

 IP: DHCP from fbcproxy
 OS: SUSE 10-64bit
 FQDN: razor.theendlesshome.com
 NIS Client: fbc.nis
 W2K3 Domain: theendlesshome.com

razor-vm-xp

Very similar to the Windows XP on whit. Just another Windows XP SP2 client host.

razor-vm-xp - VMware Guest OS on razor

Virtual Machine, 512MB

 IP: DHCP from fbcproxy
 OS: Windows XP SP2
 FQDN: razor-vm-xp.theendlesshome.com
 W2K3 Domain: theendlesshome.com

fc5-vm-fedora

Fedora Core 5 (beta 2) with NIS, but without joining the Windows Domain.

fc5-vm-fedora - VMware Guest OS on razor

Virtual Machine, 512MB

 IP: DHCP from fbcproxy
 OS: Fedora Core 5 (beta 2)
 FQDN: fc5-vm-fedora.theendlesshome.com
 NIS Client: fbc.nis

0-c-29-ab-e0-d8

Ubuntu, but without NIS or Windows Domain support. Hostname reflects the default assignment in DNS when no hostname is provided by the DHCP client. The name is derived from the MAC address of the network interface.

0-c-29-ab-e0-d8 - VMware Guest OS on razor

Virtual Machine, 512MB

 IP: DHCP from fbcproxy
 OS: Ubuntu 5.10 (Breazy Badger)
 FQDN: 0-c-29-ab-e0-d8.theendlesshome.com

Dynamic DNS/DHCP

DNS Overview

At the heart of Dynamic DNS (DDNS) will be ISC's dhcpd server and their DNS name server, BIND. Both products are free and are "reference" implementations of their respective protocols. However, both are robust enough for enterprise use.

In short, DNS is a service that allows people to use a friendly name rather than an IP address to get at a network resource. For example, instead of typing http://192.168.44.6 in my browser address bar, I can use http://mywebserver.org. DNS on the internet is hierarchical and scales well, allowing you to lookup and use IP addresses by name for any host on the internet. Your source for DNS comes from your network provider. On a Linux/Unix host, the DNS server address that will be used for name to IP resolution is stored in /etc/resolv.conf. DNS name to IP mappings are housed on what are called "zones" by the DNS server. A DNS Server that holds the actual records for a particular zone is said to have "authority" over that zone. There is NOT necessarily a one for one correlation between an internet domain and a DNS zone.

Since DNS is a hierarchical database of entries, the root(s) must be universally known. From there we have what are called the Top Level Domains, TLDs (.com, .edu, .org, .net, etc.) and underneath that are zones which are delegated out to the servers which are authoritative for that zone, which in turn might have sub-zones of authority, etc. Ultimately the Fully Qualified Domain Name (FQDN) results in a successful lookup of an "A" (Address) record which contains the IP associated with the name. Doing the reverse, IP to name, is a bit more difficult since it is hard to determine the complexities of ownership for range of IP addresses. By convention, these "PTR" records are rooted in a zone called "in-addr.arpa" (a hint as to the origins of the internet). Delegating authority for these "PTR" records is not always possible and therefore you can not guarantee that there will be a corresponding "PTR" record for all "A" records.

DNS is also used to house information about the mail exchanger for a given domain. This determines where to send mail destined for a particular domain. Microsoft has also extended the semantics of DNS by including special zones to house special lookup and discovery records for a domain that are of interest in a network using Active Directory.

DHCP Overview

Dynamic Host Configuration Protocol, DHCP, is a way of centralizing the management and configuration of network clients. DHCP is primarily responsible for assigning a temporarily leased IP address to a client host. However, DHCP can also help assist in pointing a host to other infrastructure pieces including the default gateway, DNS servers, NIS domain, Windows name servers, etc.

DDNS Implementation

Originally, DNS servers housed their records in the form of a manually edited database of entries. In order to add a new record, a file was edited, an entry was made, a special serial number entry was incremented and the server was sent a signal to reload the edited zone or was simply restarted.

However, it is much more convenient to send a message directly to the server with a record to be inserted, updated or deleted and have the server adjust itself based on that message. This is called Dynamic DNS (DDNS).

As you may have guessed, DDNS is not only useful for adding arbitrary records by message, but could also be exploited by the DHCP server to allow it to make updates to DNS automatically when a client comes onto the network. The combination of DHCP making updates directly to DNS is also called DDNS even though it is a special example of DDNS.

On fbcproxy we will create an /etc/named.conf file which will hold the configuration information for ISC's BIND DNS server. For sure we know that we want a zone to hold records for theendlesshome.com and we will want records for the reverse IP to name addresses which will be 44.168.192.in-addr.arpa.

 zone "44.168.192.in-addr.arpa" in {
        type master;
        file "master/44.168.192.in-addr.arpa";
 };
 zone "theendlesshome.com" in {
        type master;
        file "master/theendlesshome.com";
 };

However, this is not really enough to support DDNS. We could simply allow for dynamic updates to these zones to come from particular IP addresses only (which is somewhat secure), but instead we are going to create a special key which will allow dynamic updates only from those who can successfully sign their messages using the special key. The type of signing key we will use is called a Transaction SIGnature, TSIG, key. You can easily create a TSIG key using a utility that comes with ISC's BIND server called dnssec-keygen.

 dnssec-keygen -a HMAC-MD5 -b 128 -n USER FBC_UPDATER

The output Kfbc_updater.+157+38509.key file contains a cryptic string that we can use to define a key in our /etc/named.conf file.

 key FBC_UPDATER {
        algorithm hmac-md5;
        secret "cw4fCmKNv9GZ9ygHab2ynA==";
 };

Now we will allow updates from those possessing the ability to sign using this key and we will also allow such the ability to dump all of our records in something called zone transfer (zone transfers are used by slave DNS servers to receive updates/changes from a master DNS server).

 zone "44.168.192.in-addr.arpa" in {
        type master;
        allow-update { key FBC_UPDATER; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/44.168.192.in-addr.arpa";
 };
 zone "theendlesshome.com" in {
        type master;
        allow-update { key FBC_UPDATER; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/theendlesshome.com";
 };

In order to support Windows Domain Member Servers on the network, we will have to add additional zones and provide some way for those Windows hosts to make dynamic updates. Unfortunately, Windows does not support TSIG, so we will allow those updates by IP. It probably does no harm for us to allow TSIG updates to those zones as well, just in case we're forced to clean up something that Windows is not able to handle well. In all the zones we will allow localhost to update (or leave it out and always used TSIG).

 acl domain-controllers { 192.168.44.33; };
 zone "_udp.theendlesshome.com" in {
        type master;
        allow-update { key FBC_UPDATER; domain-controllers; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/_udp.theendlesshome.com";
 };
 zone "_msdcs.theendlesshome.com" in {
        type master;
        allow-update { key FBC_UPDATER; domain-controllers; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/_msdcs.theendlesshome.com";
 };
 zone "_sites.theendlesshome.com" in {
        type master;
        allow-update { key FBC_UPDATER; domain-controllers; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/_sites.theendlesshome.com";
 };
 zone "_tcp.theendlesshome.com" in {
        type master;
        allow-update { key FBC_UPDATER; domain-controllers; };
        allow-transfer { localhost; key FBC_UPDATER; };
        file "master/_tcp.theendlesshome.com";
 };

That is the heart of the /etc/named.conf file, but I am skipping quite a bit. The full file can be viewed here (/etc/named.conf).

For each of the files mentioned within the zone declarations, we will need to create a starting template zone database (a text file). On a SUSE Linux box, the zone databases as well as all configuration data will end housed in /var/lib/named. This is because SUSE's BIND implementation runs in a chroot jail for security reasons. So under /var/lib/named/master we need to create files for master/theendlesshome.com, master/44.168.192.in-addr.arpa, etc, etc.

Each file will be similar to the following one for master/theendlesshome.com.

 @      IN SOA  fbcproxy.theendlesshome.com. itqb.theendlesshome.com. (
                                 2005010679 ; serial
                                 10800      ; refresh (3 hours), could have said 3h
                                 3600       ; retry (1 hour), could have said 1h
                                 604800     ; expire (1 week), could have said 1w
                                 86400      ; minimum (1 day). could have said 1d
                                 )
                         NS      fbcproxy.theendlesshome.com.
                         A       192.168.44.6
 fbcproxy                A       192.168.44.6

The @ in the first line is a shorthand notation for the zone in context and our file in this case is associated with the zone theendlesshome.com in our /etc/named.conf. The notation IN SOA simply means INternet Start Of Authority which is then followed by a FQDN of our DNS name server (do not forget the trailing dot!). Finally, itqb.theendlesshome.com. will be translated to itqb@theendlesshome.com which will serve as the email address associated with this zone (in case someone discovers problems with it). There are two A records in this zone already, Once is for the NS (Name Server) itself and the others simply means that name theendlesshome.com by itself will have the address 192.168.44.6.

The serial field is used to notify dependent servers that a change as been made. Under DDNS, this field will get incremented for us with every dynamic update made. It is somewhat traditional to seed the serial number value with the date of the zone's creation, but this is merely a common convention. The refresh is time by which DNS slaves checks to see if their zone data is up to date. The retry is the interval that a slave will attempt to do a refresh after getting a failure. The expire is the interval for data to be held before being discarded by the slaves when the master cannot be reached. Finally, the minimum specifies the Time To Live (TTL) for negative responses from the server. In the good ole days, the intervals had to specified in seconds, but now you can use abbreviations, d=day, w=week, h=hours, m=minutes. Also the values could be combined, like 2d2h5m.

For DDNS to work, these database files and the directory they reside in must be writable by the BIND process. In our case, the named daemon runs in a chroot jail as the user called named. When dynamic updates are made to the zones, a high speed .jnl binary file will be used/created to store the updates and then that data will be migrated to the actual textual zone database file over time or when the server is shutdown.

DO NOT hand edit the text database files while the server is up and running. Also, if there are *.jnl files present after shutdown of named, it is wise to remove them if you are going to make manual updates to the text database files. In general though, as long as there are no radical changes to the configuration, the text database files will never be hand edited again.

Just for completeness, here is the reverse PTR zone SOA and PTR entry for fbcproxy:

 44.168.192.in-addr.arpa IN SOA  fbcproxy. itqb.theendlesshome.com. (
                                 2005010631 ; serial
                                 10800      ; refresh (3 hours)
                                 3600       ; retry (1 hour)
                                 604800     ; expire (1 week)
                                 86400      ; minimum (1 day)
                                 )
                         NS      fbcproxy.theendlesshome.com.
 6                       PTR     fbcproxy.theendlesshome.com.

Notice the use of PTR instead of A when describing the IP mapping back to name.

If you're running SUSE, you may find it easier to let SUSE's YaST create the zone database files for you. YaST can be used to manage DNS in a non-dynamic fashion. It is not useful when using DDNS, but can be used to at least get the zone files started.

DNS Testing

To test your zones, you should be able to do either host fbcproxy, dig fbcproxy or nslookup fbcproxy and see the name to IP mapping for fbcproxy (similarly you can check the reverse, host 192.168.44.6). Also, from the name server host you should be able to dump an entire zone with a command like host -l -a theendlesshome.com or dig -t AXFR theendlesshome.com. If either of these fail, then I am afraid it's time to some extra research and troubleshooting. I highly recommend the O'Reilly book DNS and BIND by Paul Albitz and Cricket Liu.

DHCP Implementation

The DHCP configuration is simpler. We simply add an additional parameter to a normal /etc/dhcpcd.conf file plus the TSIG key information from above.

 # dhcpd.conf
 # 
 authoritative;

 # This prevents clients from updating their own information, we
 # will instead parse the client supplied options and make
 # the selection of hostname and domainname.
 deny client-updates;

 # This forces the domain name here If you want different domain names for
 # different clients, you can override this name in a more specific
 # scope - at group, subnet, pool or even host level.
 #
 option domain-name-servers 192.168.44.6;
 option netbios-name-servers 192.168.44.33;
 option ntp-servers 192.168.44.6;
 option nis-domain "fbc.nis";
 option nis-servers 192.168.44.6;
 ddns-domainname "theendlesshome.com";
 option domain-name "theendlesshome.com";
 max-lease-time 300;
 default-lease-time 300;

 # Generate DNS names for clients who don't provide a
 # host-name... the generated names will be ASCII representations
 # of the clients' MAC addresses.  See notes below on variations for
 # fixed-address hosts.
 ddns-hostname = pick (option fqdn.hostname, option host-name,
         binary-to-ascii (16, 8, "-", substring (hardware, 1, 6)));

 # DDNS is still in flux, hence the term "interim". If you are using DDNS,
 # this line has to be here.
 ddns-update-style interim;

 key FBC_UPDATER {
         algorithm hmac-md5;
         secret "cw4fCmKNv9GZ9ygHab2ynA==";
 }

 # Describe primary forward dynamic ddns zone allowing updates
 zone theendlesshome.com. {
         primary 192.168.44.6;
         key FBC_UPDATER;
 }


 # Describe reverse DNS zones allowing updates
 zone 44.168.192.in-addr.arpa. {
         primary 192.168.44.6;
         key FBC_UPDATER;
 }

In Window, normally updates to DNS are done by the clients themselves. Here we specify deny client-updates to prevent this. Our DHCP server or our own programs will be used to make DNS updates. I am using a very short lease time here. Regardless, it is probably wise for it to be somewhat short just so DHCP can recover from potentially conflicting things.

Lastly, we need to setup a pool range. ISC's DHCP Server also supports the idea of a failover DHCP server. In that arrangement, each server administrates half of the overall pool of addresses. Our implementation will just have a single DHCP server. Here is the pool:

 subnet 192.168.44.0 netmask 255.255.255.0
 {
         option routers 192.168.44.6 ;

         pool
         {
                 deny dynamic bootp clients ;
                 range 192.168.44.100 192.168.44.200 ;
         }
 }

You can see the full file here (/etc/dhcpd.conf).

NFS and Samba Server

Sharing file shares or folders across a network in Unix/Linux is often done with the Network File System (NFS). On Windows, file sharing is done through SMB protocol (or CIFS). This protocol can be used from a Unix/Linux host by using a program called Samba. In our example, we need to be able to share directories both ways so that we can centralize the location of the home directories for Unix/Linux clients as well as Windows clients.

NFS Implementation

Create a new filesystem and mount it at /export/nfshome on fbcproxy. Then create (or add to) a file called /etc/exports and place an entry for the newly created and mounted filesystem:

 /export/nfshome *(rw,root_squash,sync,insecure)

The * means that we'll allow any host to mount our resource remotely. The root_squash parameter keeps root from being able to access the filesystem remotely (for security reasons), The sync parameter forces safer synchronous writes. Finally, insecure if primarily of value to older Unix machines which might allow high numbered ports to access NFS (allowing any user the ability to potentially hack and/or monitor NFS traffic).

The NFS daemon is called nfsd, but typically you should be able to start the NFS Server by executing the init startup script /etc/init.d/nfsserver start.

NFS Testing

Using another Unix/Linux client host create a mount point and attempt to mount it there.

 mkdir /tmp/nfshome
 mount fbcproxy:/export/nfshome /tmp/nfshome
 ls /tmp/nfshome
 umount /tmp/nfshome

Samba Implementation

Our Windows Domain Controller is w2k3 and I will assume that you have configured a domain called theendlessnow.com there. On fbcproxy we will need a Samba configuration that will allow us to join the domain.

Begin with some global section settings:

 [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

Security is DOMAIN because we will be joining with the w2k3 domain controller and we want to authenticate our passwords through it. The winbind trusted domains only and winbind use default domain will allow easy mapping of id's of the form THEENDLESSHOME\username to a Linux username. For special cases, we can to arbitrary mappings via the /etc/samba/smbusers file. Raising the log level to something high will help you pinpoint problems while setting all of this up. Afterwards, you can lower it back down to 2 or 3.

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

The homes share is what we will map to H: for each user in Windows. Here is the User Profile properties window on w2k3 for the user alcox:

The value of \\fbcproxy\homes is defined to be the Unix/Linux home directory of the user. If you do not like the Windows home directory to be the exact same, you can alter your user skeleton on fbcproxy and create a sub-directory to hold your Windows files (e.g. \\fbcproxy\homes\winhome).

Ignore the Profile Path for right now.

Assuming we have started our smbd and nmbd daemons on fbcproxy (/etc/init.d/smb start; /etc/init.d/nmb start), and assuming that there is a user on fbcproxy called alcox, when Angela logs in, her Linux/Unix home directory will be mapped as H: and will be used as her Windows home directory. We could have just as easily mapped H: to \\fbcproxy\%username%, but I like exploiting the Samba homes features.

W2K3 Domain Controller

To be done.

NIS

Network Information Service is a simple protocol that allow you to push out lookup services to remote clients. Lookups CAN include: usernames/groups, hosts and automountable shares. There is no good reason to push out hosts maps anymore with NIS since DNS is the preferred mechanism.

What makes NIS so easy to use is the fact that the source of the maps being pushed out can be the /etc/* files you have already setup on a host.

NIS was originally called Yellow Pages, so you will see the yp prefix on many of the NIS tools. [cough] Somebody did not appreciate Sun Microsystems use of the phrase Yellow Pages. [cough]

NIS Server Implementation

On fbcproxy will install ypserv and ypbind. The fbcproxy host will be our NIS Master. All NIS clients just need ypbind installed. Normally, we would also install ypserv on one or more NIS Slave servers. Just having a single NIS Master is good enough for our example.

Depending on the NIS implementation, you will need to locate the Makefile used to create the maps on the NIS Master. Since we're using SUSE on fbcproxy, the Makefile is located at /var/yp (which is one of the most common locations for this). We have to manually edit the Makefile there to determine what NIS maps we want to create and push out.

Locate the all: target line in Makefile. By default on SUSE, the line looks like:

 all: passwd group rpc services netid

On some default implementations, you'll see a myriad of maps being built and pushed like:

 all:  passwd group hosts rpc services netid protocols netgrp mail \
       shadow publickey # networks ethers bootparams printcap \
       amd.home auto.master auto.home auto.local passwd.adjunct \
       timezone locale netmasks

We will change the maps for our use to:

 all: auto.home auto.master group netgrp netid passwd

Sorry about the order, they are alphabetized.

The passwd and group maps are fairly obvious, EXCEPT, the encrypted passwords which would normally be located in a local /etc/shadow file are merged into the passwd field of the passwd map. We will see this later on. This is where the insecurity of NIS is. Because the encrypted passwords are pushed as part of the map, anyone can tap the set of encrypted passwords and run brute force cracks against the passwords!! A reasonably strong passwords of 8 characters could take many months to crack, but it is possible. Weak passwords could be cracked within a matter of SECONDS!

The netgrp (netgroup) map is used so we can push out a set of username and/or hostname groupings that can be used to restrict NIS use on a given client. This is one of the most powerful and yet underutilized features of NIS. With it we can attach a client to our NIS and restrict the access to one particular netgroup of users, or deny access to a different set, etc.

The auto.master and auto.home maps are used to push out information about how to automatically mount the user's home directory when logging into a Unix/Linux NIS client host.

SUSE's Makefile makes it easy to filter the passwd and group maps to a limited set of UIDs and GIDs. We would not want to push out a map with the root id in for example. In SUSE's Makefile we will define:

 MINUID=5000
 MINGID=6

This way we only push UIDs that are larger than 5000 and GIDs that are larger than 6. That group id may seem a bit low, but Linux requires users to have access to several system level groups in order to have enough permissions to access certain device resources (e.g. disk, audio, video). We will assume that the there is SOME uniformity on the lower numbered GIDs (certainly no guarantee especially on the non-Linux platforms).

NIS Server Auto Mounter Maps

The auto.master and auto.home maps are ways to tell clients how to automatically mount up available network shares. For portability I recommend that you only use what are called indirect auto mount shares in your maps. An indirect map entry is one that mounts the shares underneath a logical directory and that logical directory only houses other automount mapped shares.

Our /etc/auto.master source file on fbcproxy will contain:

 /home      auto.home

Thus we are consuming the /home directory for our automounts. You may not like this since many hosts use /home for local user home directories. I prefer to place local home directories somewhere else and so my clients use /localhome for local user home directories. The entries definitions for what is mounted under /home is located in the map for auto.home.

Our /etc/auto.home source file on fbcproxy will contain:

 nfshome    fbcproxy:/export/nfshome

On a more complicated network, you can fully qualify the fbcproxy name as needed.

The fbcproxy:/export/nfshome entry is interpreted to be a NFS mountable area. It will be mounted to /home/nfshome on the NIS clients when accessed. Since our user home directories will be of the form /home/nfshome/username, our NFS area will get automounted when users start logging in on the NIS clients.

To define our NIS name, we can set the /etc/defaultdomain file to have:

 fbc.nis

And then manually set our domainname (on reboot this is set from the /etc/defaultdomain above):

 domainname fbc.nis

Once we are done specifying our source maps on fbcproxy, the NIS versions of these maps will have to be generated. Go to the /var/yp directory on fbcproxy as root and execute:

 make

There! That was not terribly hard, was it? Anytime you make a change to the source maps in /etc on fbcproxy you will need to go to the /var/yp directory and issue a make command. There will be an exception to this if we run a @@yppasswdd@ daemon on our server, in that NIS clients will be able to make password changes (so people can change their own passwords).

Now we can start up the ypserv and yppasswdd daemons. On SUSE, you can start these using:

 /etc/init.d/ypserv start
 /etc/init.d/yppasswd start

If you know how control the execution of the init scripts on your host, you should have these start with whatever your default runlevels are.

NIS Client Implementation

Each NIS Client box will need to become a part of the fbc.nis. In fact, it is wise to have your NIS Server be a NIS Client of itself. About the only difference is that the NIS Server SHOULD NOT use the NIS information for the purposes of lookups especially in the case of usernames/groups (the original source maps for those are already on the host!).

Name lookup resolution on a NIS Client is usually controlled with a file called /etc/nsswitch.conf. So on each NIS Client we will want to edit the /etc/nsswitch.conf file to control how and when NIS lookups are to be used.

The /etc/nsswitch.conf on each client (apart from the NIS Server.. we will deal with that in a moment) should look like:

 passwd:     compat
 group:      compat

 hosts:      files lwres dns
 networks:   files dns

 services:   files
 protocols:  files
 rpc:        files
 ethers:     files
 netmasks:   files
 netgroup:   nis
 publickey:  files

 bootparams: files
 automount:  files nis
 aliases:    files

In particular, lines with compat or nis are the ones that interest us the most. The compat lines will allow the NIS Client to use their local /etc/passwd and /etc/group files, but extends them to restricted entries off of the NIS maps based optionally off of any defined netgroups. Whew! That was a mouthful. Without going into detail about netgroups, all you need it to add a line to your NIS Client's /etc/passwd and /etc/group (and on most machines, also /etc/shadow) to allow compat to work.

At the end of /etc/passwd add:

 +::::::

At the end of /etc/group add:

 +:::

At the end of /etc/shadow add:

 +::::::::

All of these lines simple mean to add the entries from the NIS maps to augment our own files. If you have not guessed, compat allows us to selectively add only users we want (e.g. +alcox) and we can also add based on netgroups (e.g. +@goodusers). Likewise, we can subtract. So be part of NIS as a client and disallow all NIS users, we could use -:::::: at the end of /etc/passwd, or just deny one user, -alcox, etc.

Separately, like on our fbcproxy server, we could use the /etc/nsswitch.conf to disallow usage of NIS for lookups:

 passwd:     files
 group:      files

 hosts:      files dns
 networks:   files dns

 services:   files
 protocols:  files
 rpc:        files
 ethers:     files
 netmasks:   files
 netgroup:   files
 publickey:  files

 bootparams: files
 automount:  files
 aliases:    files

So while fbcproxy will be an NIS Client, it will not pay attention to any of the data provided.

In order to bind ourselves to the fbc.nis domain, we need to set our domainname. Just like in the case of the NIS Server, edit /etc/defaultdomain to have:

 fbc.nis

And manually set our domain using:

 domainame fbc.nis

If you are using Solaris or possibly other Unix hosts, you can use the ypinit -c command to easily setup binding to the NIS domain. If this tools does not exist (or you do not have access to an administration tool like SUSE's YaST to do this for you), you can manually create/edit the /etc/yp.conf file and add an entry like:

 ypserver 192.168.44.6

If you use the hostname in the file, realize that you will have to have a static /etc/host definition for that hostname to prevent NIS from being dependent on a remote source of name to IP lookups. This is especially important on non-Linux hosts which tend to have great difficulties dealing with unforeseen network problems.

Finally, we can start the ypbind daemon to join the NIS Client to our fbc.nis domain. Again, you would generally call the init script to start the service:

 /etc/init.d/ypbind start

On Solaris 10 (sol10 in our example), you use ypinit -c to join to the NIS domain and start the service with:

 svcadm enable nis/client

NIS Client Auto Mount Service

In order to see the NFS home directories, we need to have an automounter daemon running on NIS Client platforms. If you have made it this far, it is a simple matter of starting the daemon:

 /etc/init.d/autofs start

On Solaris 10:

 svcadm enable autofs

Apart from Solaris 10, you will want to add the ypbind, autofs init scripts to your runlevel processes. The svcadm enable on Solaris 10 did this (effectively) for you.

NIS Client Testing

Test to see if you are bound to the NIS domain:

 ypwhich

See if you can pull a map manually:

 ypcat passwd

Try to become an NIS user:

 su - alcox

If everything worked, but the last item, the error message may indicate that there is no user directory for alcox, in which case the automounter is not configured correctly. If the login fails, then there could be a problem with your /etc/nsswitch.conf or /etc/passwd file, or the user may be trying to use a shell that is not installed on your system. As you can tell, there are quite a few things to check when things are failing.

Joining the Domain

Using the /etc/samba/smb.conf configuration (just the global part) given in Samba Implementation?, you can use this to join to the Windows domain off of w2k3. As root:

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

You will need to know the id and password of any Domain Administrator (does not HAVE to be Administrator) in order to join to the Windows domain.

Testing your ADS join

You can use:

 net ads testjoin
 Join is OK

To see if your host is properly joined to the Windows domain. You can also try to enumerate the users from the domain with:

 net user -U Administrator
 Administrator's password:
 Administrator
 Guest
 IUSR_W2K3
 IWAM_W2K3
 SUPPORT_388945a0
 krbtgt
 Mobile User Tmpl
 User Tmpl
 Power User Tmpl
 Administrator Tmpl
 SBS Backup User
 SBS STS Worker
 DC66C7D7-DE99-4643-8
 ccox
 alcox

If you get back a list of user defined on the domain, then you are probably ready good to go!

Using Domain Passwords

It is possible to use the Windows domain password instead of the NIS or /etc/shadow password on a given host. As long as there exists a mapping for the Windows username to the Unix/Linux/NIS username, you can use pam_smb to authenticate passwords to the Windows password server (usually the Domain Controller... w2k3).

Install the pam_smb software on your host and configure your /etc/pam.d area for the type of service for which you desire Windows password authentication. The file /etc/pam_smb.conf needs to be created/edited to contain:

THEENDLESSHOME,W2K3,W2K3

This will tell the pamsmbd daemon what Domain and Domain Controller to use (we have repeated W2K3 for the Backup Domain Controller since we don't have one). You will then need to start the pamsmbd daemon:

 /etc/init.d/pamsmbd start

Again, you will want to add this to automatically start for your default runlevels.

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

After this change is made, you should be able to log into this host using your Windows password OR your local or NIS password.

You may notice a longer delay when logging in since both the local/NIS and Windows systems will be checked.

Creating Users Automatically

So... .we now have two independent user databases. The NIS maps, and the Windows Domain. We have shown that the two areas can be associated with each other allowing us to blur the lines with regards to password authentication. However, what we truly desire is a system that will allow us to create a user ONCE on one system and have it immediately available throughout the entire network.

Samba provides a means by which a program can be invoked on a samba server whenever a request is made from a client and there is NO local user on the samba server host. The option in samba is called add user script. We will use that to automatically add a new NIS user to our NIS maps on fbcproxy when a user tries to access their home directory for the first time when they log in from a Windows client.

The downside is that for this to work, the user must login from a Windows client of the Windows Domain. If this does not apply to a user (a user that never uses Windows), then you can create the user normally and do a normal NIS push. But that does mean that there could be a difference between the users defined on the Windows domain and those defined strictly in NIS. I would recommend that the Windows Domain administrator perform a Windows based login on behalf of the user to force the creation on his/her behalf.

Ideally, when we are totally done with all of this, we will have a system where if a user exists on the Windows Domain, they can log in, if not, they cannot log in. The goal is to centralize the management of users. Since Windows is a curse we live with and since Windows is not friendly towards non-Windows OS's, it makes sense to let Windows own the master source of usernames on the network and allow Unix/Linux to integrate with it.

Inside of the [global] section of our /etc/samba/smb.conf file on fbcproxy we will add:

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

Then we will create the /usr/local/sbin/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 $?
 

In short, this will create the user, change their home directory to use the auto mounted version of the home directory and change their encrypted password string to OkBadPassword. Ideally, the encrypted password should be a salted DES string corresponding to a password that can NEVER be typed. Why? This will allow us to get rid of the annoying security problem of NIS, the encrypted passwords inside of the passwd map. What this means is that NIS password authentication will always fail, forcing us to use the Windows domain for all password authentication (or by using some other means).

When complete, we should be able to create a new user on the Windows Domain, log in using a Windows client and verify that the user's home area is mounted under H: and that the user does have a NIS passwd map entry containing the OkBadPassword DES encrypted string.

Test Automatic User Creation

A picture is worth a thousand words. Let's create a new user called Joe User with a username of juser.

On w2k3:

Optionally, we can use a template. Templates are pretty powerless on Windows. Has mostly to do with what groups a user is associated with. By assigning Joe User to the normal User Template, he will not be able to do too much under Windows.

Microsoft has TRIED to make their system more secure, and restricting users is certainly a part of that. However, most organizations are forced to give users more liberal (powerful) group assignments because the normal User Template is so restricted. I have seen many shops put all of their user into the Administrator Template just to avoid frustration!!!

When complete we should see the account creation summary.

Unfortunately, the account creation wizard does not let us adjust things like the user's home directory. So after the account is created, double-click or do a Properties on the user's account and go to the Profile tab and add the mapping of H: to \\fbcproxy\homes:

Of course, Windows does not understand the bit of Samba magic that allows each user to use \\fbcproxy\homes have that take them straight into their particular home directory.

Personally, I love the look on a Windows Administrator's face when they see this one! They'll usually hammer you for hours about why this could NEVER work!!

Just click OK to the warning below.

Now we are ready to login as our new user. We can do that from any Window XP client.

Bring up the My Computer area for Joe User and see that the H: drive is mounted. Believe it or not, this is probably good enough to say everything is fine!

But for those who have to have extra verification. We should be able to go onto any NIS Client and view the juser entry. For example, on fbcproxy:

 ypcat passwd | grep juser
 juser:OkBadPassword:5006:5000::/home/nfshome/juser:/bin/bash

Since we have a bad NIS password, on any NIS Client that also has the pam_smb change we made above, we should be able to log into that server using the Windows password.

PuTTY and SSH Keys

Wow. So we have Single Sign On, right? Well, no. If we are on a Windows XP client logged in as juser, when I bring up PuTTY or some other SSH client to login to a Unix/Linux host, at best, I still have to issue a password, even if it is my Windows password.

[Sigh] That's not Single Sign On, all we've done is centralized our user account and password information.

The key to Single Sign On is the use of SSH keys. The idea is to create a public and private key where the public key is stored on every server on the Unix/Linux network. Fortunately, by storing the public key into an area on the network shared home directory of the user, that means we only have to put that into place once for the entire network! The SSH private key is then used on the client host (Windows XP) as the ticket into the Linux/Unix hosts WITHOUT using a password. And that's Single Sign On.

What's more is that with SSH keys in place, our Linux/Unix hosts DO NOT have to use the pam_smb trick above. We will not need to authenticate passwords at all. This means that without access to the SSH private key for an individual, there is no way to login as that individual!

Install and Configure PuTTY

The easiest way to find PuTTY is by using http://www.google.com. Just search for PuTTY and it should be the first entry. If that does not work, try searching for PuTTY SSH. The current location for PuTTY is http://www.chiark.greenend.org.uk/~sgtatham/putty/ as of this writing. PuTTY is a free SSH and telnet client for Windows. Under the downloads area of the web site you will find an Windows-style installer (x86 only) .exe file that you can download and run to install PuTTY onto your clients. Because of the way PuTTY installs and works, I am not sure if it is possible to create a Group Policy Object to force the install of PuTTY on Windows Domain clients. I did not try this... feel free to try this yourself (for all of the MCSE's).

Once PuTTY is installed, login as a regular user (e.g. juser) and bring up the PuTTYgen client. The PuTTYgen program is used to create SSH keys. Select that we are wanting to create an SSH2 RSA key type (SSH1 is very insecure). Click on the Generate button and wiggle your mouse as directed to create some randomness. Once the key is generated, enter a passphrase which will be used to unlock the user of your private key when needed.

Save your private key onto your H: drive into a directory you will need to create called putty. Name the private key, putty_rsa. When saved, the extension .PPK will be added to the file. Now go ahead and save your public key (though it's not used) as putty_rsa.pub into the same directory. Leave the PuTTYgen window OPEN, we need the OpenSSH key text from the window in a minute!!

Bring up a PuTTY client. We will use that to open an SSH session to an existing NIS client host. It needs to be a host has the pam_smb trick installed on it, otherwise, we cannot login since our NIS password is worthless. Let's use wiht.

See the PuTTYgen window in the background, hope you didn't get rid of it.

Click on the SSH area on the far left and change the SSH protocol to SSH2 before attempting to login. Go back to the Session panel and enter the name wiht into the Saved Sessions pane and click Save. Now click Open to open up the session to wiht.

See the PuTTYgen window in the background, hope you didn't get rid of it.

Assuming that you successfully logged in, we now need to put the OpenSSH from the PuTTYgen window into a special file in our home directory via wiht. Copy the OpenSSH key.

Now you will need to create an .ssh directory for juser on wiht and append the copied data into .ssh/authorized_keys2. Create the directory using mkdir .ssh and change the permissions so only juser can use it, chmod 700 .ssh. Then using cat we will append to the .ssh/authorized_keys2 file. Type Control-D when done to close out the file.

Now we can bring up the PuTTY pageant program which will place an icon onto your task bar. Right click on the icon and do Add Key. Locate the private key from your home directory and select it. You will be prompted for your passphrase. Enter your passphrase and then bring up PuTTY again and log into wiht. This time, when you login as juser, you will not have to issue juser's password.

You can edit your wiht Saved Session by doing a Load and go to the Connection area and add juser as your Auto-login username. Then go back to Session and Save it.

Now when you bring up your wiht Saved Session, you should go straight to a prompt. That's Single Single On!!

Domain Mandatory Roaming Profile

It is possible to automate the calling of pageant with your private key file. If you know how to create a Mandatory Roaming Profile, you can add to the Start Up area a shortcut to invoke pageant h:\putty\putty_rsa.PPK which will load your private key at login time.

Then you can go into the Properties for the user on the Domain Controller and change their Profile -> Profile Path: to be the master profile containing the pageant shortcut. Setting up a Windows Roaming Profile is an advanced topic, but should be well understood by your Windows MCSE.

You can always place a shortcut into your own local Start Up if you do not know how to setup a Mandatory Roaming Profile.

Conclusion

As complicated as this may all seem, this is not difficult to setup if you already have a fundamental understanding of NIS, SSH, NFS and some Windows Domain experience.

Page last modified on April 25, 2012, at 09:10 PM