CIFS/9000 is the software we use on HP-UX to share files and printers with Windows (and OS/2) based servers using the underlying protocol that Windows uses for browsing—Server Message Blocks (SMB). To many UNIX administrators, the thought of working hand-in-hand with a Windows server is something akin to sacrilege. Regardless of your view of Windows, everyone has to admit that the prevalence of Windows on the desktop is nothing short of amazing. The fact that it is now infiltrating the computer-room is a testament to its increasing maturity and acceptance by IT managers as a corporate-level operating system.
When HP-UX 10.20 was the most recent version of HP-UX, CIFS/9000 wasn't available. If you were an HP-UX administrator and you wanted to integrate file sharing between HP-UX and Windows-based machines, you had three choices: purchase ASU/9000 (Advanced Server for UNIX, previously known as LanManager for UNIX), purchase PC-NFS, or use the freeware software known as SAMBA. Because it's freeware, HP would not offer any official support for the SAMBA software if you had problems. The adoption of CIFS as an official product has rectified this situation. Is CIFS/9000 based on SAMBA? Yes, very much so, although HP has augmented the software to support integration with PAM and Kerberos authentication as well as ONC AutoFS 2.3 (on HP-UX 11i version 2 not version 1) support. As of version 1.08, an HP-UX CIFS server can even act as a Primary Domain Controller, be a Browse Master, map Windows NT/XP/2000 Access Control Lists to UNIX permissions via HFS or VxFS ACLs, and provide NT printing support by uploading or downloading the necessary printer drivers from a Windows Server or client if necessary. CIFS is a protocol that supports remote file access. It was formerly known as SMB. Are CIFS and SMB the same? Yes, they are identical. In fact, Microsoft acknowledges that CIFS is simply a name change from SMB. The name change reflects the extent by which CIFS is now supported on other operating systems: UNIX, VMS, and MAC-OS to name a few. Whether we can ever consider it as a true Internet filesystem is a bit strong in my view, but the idea of operating system independence is a good one if not new; NFS was the de facto standard for file sharing on UNIX platforms for many years. The configuration files used on HP-UX are similar in format to other UNIX flavors, which makes life easier if you have configured CIFS/SAMBA on another version of UNIX. As you would expect, an HP-UX machine can act as a CIFS server, a CIFS client, or even both simultaneously.
We can install the software from our source media, or we can download it free of charge from http://software.hp.com → “Internet ready and networking” currently titled “hp cifs client” and “hp cifs server”. We can install either the client or the server component separately; it depends on what you are looking to achieve. Installing the software is a simple matter of a swinstall, although installing the CIFS-client software does require a reboot; the kernel needs to recognize CIFS as a valid filesystem type. If you have used an HP-UX 11i Operating Environment, you may have CIFS/9000 already installed; CIFS/9000 is part of the basic Operating Environment.
root@hpeos001[] #_swlist -l product -s /cdrom HPUX11i-OE | grep -i cifs HPUX11i-OE.CIFS-Server A.01.08 CIFS/9000 (Samba) File and Print Services HPUX11i-OE.CIFS-Development A.01.08 CIFS/9000 server source code files HPUX11i-OE.CIFS-Client A.01.08 HP CIFS/9000 Client root@hpeos001[] #
Checking is a simple matter of an swlist. Okay, so we installed it. What's next?
A primary concern of a CIFS server is how to authenticate a CIFS client. There are two options:
Windows NT LanManager authentication (NTLM), which is discussed in the next section.
Kerberos authentication, which necessitates a thorough understanding of Kerberos, so we will not discuss it any further in this chapter.
The main authentication method is via what is known as Windows NT LanManager (NTLM) authentication. Unlike NFS that does not ask for usernames and passwords, NTLM requires a user (a client) to log in to the CIFS server before accessing a mount point. Thereafter, we utilize file permissions and ownerships to enforce security. NTLM authentication requires a CIFS client to have a valid username and password configured in a password file located somewhere in the Windows domain. When we start talking about an administrative domain, we are talking about a Windows concept, which is a distributed environment for managing usernames, passwords, and access rights; we have concepts such as a primary domain controller (PDC) and backup domain controllers (BDC). Before you start having heart palpitations, you may initially want to authenticate users via a CIFS/SMB password file located on your HP-UX server that is not explicitly part of the Windows domain. This means we need to have a separate password file configured for all CIFS clients. It would be helpful if we could just use /etc/passwd, but life is never that simple, is it? Unfortunately, we need a separate CIFS password file to /etc/passwd; it's normally called /var/opt/samba/private/smbpasswd. As well as having a separate password file, we have a separate command to configure passwords: smbpasswd. This may seem a bit long-winded, but it actually is relatively simple to set up and does mean that your HP-UX server can authenticate CIFS clients without necessarily having a PDC/BDC configured and running. The drawback is that we now have two password files to manage on HP-UX; c'est la vie. The flipside is that with CIFS/9000 we can utilize the password file in our Windows domain; we can authenticate CIFS clients via our PDC/BDC. We look at that later. Some administrators would argue that having Windows/CIFS clients out there in out network, it might be a safe(ish) bet to assume that you have some means of authenticating them; in other words, most Windows networks will have a PDC/DBC configured. I can't comment on the number of Windows networks that use a domain (PDC/BDC) or a workgroup. We look at setting up a local SMB/CIFS password file on an HP-UX server as well as integrating our authentication with a Windows PDC/BDC.
The setup for a simple CIFS server using a local SMB/CIFS password file is relatively simple. Here's a cookbook for the setup:
Install the CIFS/9000 Server product.
Enable CIFS server functionality in
/etc/rc.config.d/samba.Configure
/etc/opt/samba/smb.conf.Verify your
smb.confconfiguration with thetestparmutility.Create a SMB password file.
Start the CIFS daemon.
Verify the configuration with the
smbclientutility.
I don't need to show you how to install software, do I? I have downloaded the most recent version of the software from http://software.hp.com and, as you can see, it does not require a reboot:
root@hpeos003[] swlist -l fileset -a is_reboot -s /tmp/B8725AA_A.01.10_HP-UX_B.11.11_32+64.depot
# Initializing...
# Contacting target "hpeos003"...
#
# Target: hpeos003:/tmp/B8725AA_A.01.10_HP-UX_B.11.11_32+64.depot
#
# CIFS-Development
CIFS-Development.CIFS-PRG false
# CIFS-Server
CIFS-Server.CIFS-ADMIN false
CIFS-Server.CIFS-DOC false
CIFS-Server.CIFS-MAN false
CIFS-Server.CIFS-RUN false
CIFS-Server.CIFS-UTIL false
root@hpeos003[]
Once it's installed, we can proceed.
This part of the configuration is simply to ensure that the CIFS server daemon is started after every reboot.
root@hpeos003[] vi /etc/rc.config.d/samba ... # # Installed at /etc/rc.config.d/samba # RUN_SAMBA=1
I will not cover every option in this file because there are quite a few. What I propose to do is to show you how to get this configuration off the ground. You can explore some of the more esoteric options for yourself. I am looking to share the directory /ora1 with my CIFS clients. Here are the changes I made to the default smb.conf file (underlined):
root@hpeos003[] vi /etc/opt/samba/smb.conf ... [global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: REDHAT4 workgroup = UKDOM1 ... # server string is the equivalent of the NT Description field server string = CIFS9000 Samba Server ... # this tells Samba to use a separate log file for each machine # that connects log file = /var/opt/samba/log.%m log level = 1 ... # Security mode. Most people will want user level security. See # security_level.txt for details. security = user ... #=========================== Share Definitions ========================= [homes] comment = Home Directories browseable = no # This one is useful for people to share files [tmp] comment = Temporary file space path = /tmp read only = no ... [ora1] comment = Shared Database Directory path = /ora1 writable = yes browseable = yes
You may notice that user home directories and /tmp are part of the default configuration. If you want to disable this feature, simply remove the [homes] and [tmp] sections from the smb.conf file. I will leave them in for this demonstration.
While not absolutely necessary, testparm will highlight any syntax errors in your smb.conf file; it's an especially good idea when you have never configured CIFS before (I will truncate this output because it covers more than seven pages).
root@hpeos003[] /opt/samba/bin/testparm
Load smb config files from /etc/opt/samba/smb.conf
Processing section "[homes]"
Processing section "[tmp]"
Processing section "[ora1]"
Loaded services file OK.
Processing comments in /etc/opt/samba/smb.conf
Press enter to see a dump of your service definitions
# Global parameters
[global]
coding system =
client code page = 850
code page directory = /etc/opt/samba/codepages
workgroup = UKDOM1
netbios name =
netbios aliases =
netbios scope =
server string = Samba Server
interfaces =
bind interfaces only = No
security = USER
encrypt passwords = Yes
update encrypted = No
allow trusted domains = Yes
hosts equiv =
...
vfs options =
msdfs root = No
[homes]
comment = Home Directories
browseable = No
[tmp]
comment = Temporary file space
path = /tmp
[ora1]
comment = Shared Database Directory
path = /ora1
As you can see, there are quite a few parameters to configure. We have taken the defaults for the vast majority of these parameters.
The SMB/CIFS password file does not exist by default. We need to create it and ensure that the permissions are correct. Again, it's not a difficult task:
root@hpeos003[] ll /var/opt/samba/private total 0 root@hpeos003[] touch /var/opt/samba/private/smbpasswd root@hpeos003[] chmod 500 /var/opt/samba/private root@hpeos003[] chmod 600 /var/opt/samba/private/smbpasswd root@hpeos003[] ll /var/opt/samba/private total 0 -rw------- 1 root sys 0 Sep 7 16:24 smbpasswd root@hpeos003[]
We can now add users into the SMB password file using the smbpasswd command. These users will exist on our CIFS client machines, either Windows clients or CIFS clients on HP-UX machines. Before we add a user to the SMB password file, the user must exist in /etc/passwd. In this example, the user fred does not exist in the /etc/passwd file:
root@hpeos003[] pwget -n charlesk charlesk:Q2BGUB0vg2nnE:103:20::/home/charlesk:/sbin/sh root@hpeos003[] /opt/samba/bin/smbpasswd -a charlesk New SMB password: Retype new SMB password: Added user charlesk. root@hpeos003[] /opt/samba/bin/smbpasswd -a fred New SMB password: Retype new SMB password: User fred does not exist in system password file (usually /etc/passwd). Cannot add account without a valid local system user. Failed to modify password entry for user fred root@hpeos003[]
We are now ready to start the CIFS daemons, smbd and nmbd. We can run the startup routine /sbin/init.d/samba:
root@hpeos003[] /sbin/init.d/samba start Samba started successfully; process ids: smbd: 3110, nmbd: 3108 root@hpeos003[] root@hpeos003[] ll /var/opt/samba total 6 drwxr-xr-x 2 root sys 1024 Sep 7 16:29 locks -rw-r--r-- 1 root sys 462 Sep 7 16:29 log.nmbd -rw-r--r-- 1 root root 162 Sep 7 16:29 log.smbd dr-x------ 2 root sys 96 Sep 7 16:26 private root@hpeos003[] more /var/opt/samba/log.smbd [2003/09/07 16:29:35, 0] smbd/server.c:(793) smbd version 2.2.8a based HP CIFS Server A.01.10 started. Copyright Andrew Tridgell and the Samba Team 1992-2002 root@hpeos003[]
The smbclient command should display our server's domain/workgroup as well as the shares that have been made available to clients. You can replace the “%” sign with a specific username if you want to see the shares available to a specific Windows user.
root@hpeos003[] /opt/samba/bin/smbclient -L localhost -U%
added interface ip=192.168.0.203 bcast=192.168.0.255 nmask=255.255.255.0
Domain=[UKDOM1] OS=[Unix] Server=[Samba 2.2.8a based HP CIFS Server A.01.10]
Sharename Type Comment
--------- ---- -------
tmp Disk Temporary file space
ora1 Disk Shared Database Directory
IPC$ IPC IPC Service (CIFS9000 Samba Server)
ADMIN$ Disk IPC Service (CIFS9000 Samba Server)
Server Comment
--------- -------
CKHOME1 The Main Machine
HPEOS003 CIFS9000 Samba Server
Workgroup Master
--------- -------
UKDOM1 CKHOME1
root@hpeos003[]
Because we are now acting as a CIFS Server, we should be able to see the configured shares on a Windows-based machine (running Windows XP in this instance) as shown in Figure 20-1.
This command was run by the Windows user charlesk. It is important that the users we add to the smbpasswd file are the same usernames (and passwords) used by Windows. We now look at setting up HP-UX as a CIFS Client, i.e., able to use shares advertised from a CIFS Server. This could be a Windows-based server or another HP-UX machine acting as a CIFS server.
We use a cookbook approach as we did for a CIFS Server. The setup of a CIFS client is similarly straightforward:
Install the CIFS/9000 Client product.
Configure
/etc/opt/cifsclient/cifsclient.cfg.Run the CIFS client startup script.
Create a mount point directory.
Add the CIFS filesystems to the
/etc/fstabfile.Mount the CIFS filesystems.
Execute the
/opt/cifsclient/bin/cifsloginprogram.Verify that your
cifsloginsucceeded.
Let's look at each step more closely.
Remember that this swinstall will require a reboot, because the kernel needs to be able to recognize CIFS as a filesystem type. The client bundle may already be installed as part of the basic HP-UX 11i Operating Environment. I have downloaded the most recent version of the client software from http://software.hp.com to use in this demonstration.
root@hpeos004[] swlist -l fileset -a is_reboot -s /tmp/B8724AA_A.01.09_HP-UX_B.11.11_32+64.depot
# Initializing...
# Contacting target "hpeos004"...
#
# Target: hpeos004:/tmp/B8724AA_A.01.09_HP-UX_B.11.11_32+64.depot
#
# CIFS-Client
CIFS-Client.CIFSCLIENT-KRN true
CIFS-Client.CIFSCLIENT-KRN true
CIFS-Client.CIFSCLIENT-MIS false
CIFS-Client.CIFSCLIENT-RUN false
# PAM-NTLM
PAM-NTLM.PAM-NTLM-RUN false
PAM-NTLM.SMB-LIB-RUN false
root@hpeos004[]
There are few configuration changes to be made in this file. The only change I had to make for this demonstration was to edit the line defining my Windows domain/workgroup:
root@hpeos004[] vi /etc/opt/cifsclient/cifsclient.cfg # Storing user passwords and mounts in the database can be disabled by # setting the following variable to "no". This may be useful for sites # where the client users can not be trusted to understand the security # implications. If the variable is not defined, it defaults to "yes". allowSaving = no; domain = "UKDOM1" // domain name sent to server
There is a command /opt/cifsclient/bin/cifsclient that we can run to start the daemon process /opt/cifsclient/sbin/cifsclientd. The more normal startup method is to configure the file /etc/rc.config.d/cifsclient to ensure that the daemon starts after reboot.
root@hpeos004[] vi /etc/rc.config.d/cifsclient
...
RUN_CIFSCLIENT=1
I will use the startup script to start the daemon:
root@hpeos004[] /sbin/init.d/cifsclient start
CIFS Client started; process id: 2943
root@hpeos004[]
We can use the cifsclient command to get the status of the daemon:
root@hpeos004[] /opt/cifsclient/bin/cifsclient status
path: /opt/cifsclient/sbin/cifsclientd
version: FILESET HP CIFS CLIENT: Version: A.01.09
Compiled on HP-UX B.11.00, s800/R390, 03/06/24 12:01:20
cifsclientd: ver_id=3050182349
cksum: 2189923982
status: The CIFS Client is up; process id 2943, started 10:56:56.
mntck: ok
root@hpeos004[]
This makes sense, because we are just about to mount a filesystem. Obviously, we will create the requisite number of mount points for all the CIFS mounts we will perform.
root@hpeos004[] mkdir /W2K.data
If you are going to have the CIFS filesystems available after every reboot, then it makes sense to add an entry to /etc/fstab. As you can see, the format of an entry for a CIFS filesystem is very similar to an entry for an NFS filesystem; the only difference is that the filesystem type is now cifs:
root@hpeos004[] vi /etc/fstab ... ckpc2:/work /W2K.data cifs defaults 0 0
Like any other mount command, we need to ensure basic TCP/IP functionality; ping and hostname lookup works.
root@hpeos004[] ping ckpc2 64 5
PING ckpc2.mshome.net: 64 byte packets
64 bytes from 192.168.0.1: icmp_seq=0. time=0. ms
64 bytes from 192.168.0.1: icmp_seq=1. time=0. ms
64 bytes from 192.168.0.1: icmp_seq=2. time=0. ms
64 bytes from 192.168.0.1: icmp_seq=3. time=0. ms
64 bytes from 192.168.0.1: icmp_seq=4. time=0. ms
----ckpc2.mshome.net PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
root@hpeos004[]
As you can see, we treat CIFS filesystems like any other. Consequently, it will be of no great surprise that the mount command is little different. We can mount individual CIFS filesystems:
root@hpeos004[] mount -F cifs ckpc2:/work /W2K.data
or we can mount all the CIFS filesystems listed in /etc/fstab:
root@hpeos004[] mount -aF cifs
The surprising thing is that when we use commands like bdf, we get an I/O error even though there is an entry in our mount table. It's not until we actually use the filesystem that we are given access to it (first, we will need to be authenticated by the CIFS server; that comes next).
root@hpeos004[] cat /etc/mnttab /dev/vg00/lvol3 / vxfs log 0 1 1063014366 /dev/vg00/lvol1 /stand hfs defaults 0 0 1063014366 /dev/vg00/lvol8 /var vxfs delaylog 0 0 1063014369 /dev/vg00/lvol7 /usr vxfs delaylog 0 0 1063014369 /dev/vg00/lvol4 /tmp vxfs delaylog 0 0 1063014369 /dev/vg00/lvol6 /opt vxfs delaylog 0 0 1063014370 /dev/vg00/lvol5 /home vxfs delaylog 0 0 1063014370 hpeos004:(pid664) /net ignore ro,intr,port=839,map=-hosts,indirect,dev=0000 0 0 1063014434 ckpc2:/work /W2K.data cifs soft,noac,retrans=3,timeo=200,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,NFSv3 0 0 1063015373 root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051483 235369 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 51598 435565 11% /var /dev/vg00/lvol7 917504 753622 153675 83% /usr /dev/vg00/lvol4 65536 2237 59347 4% /tmp /dev/vg00/lvol6 851968 649867 189695 77% /opt /dev/vg00/lvol5 24576 1390 21740 6% /home NFS access failed for server ckpc2: RPC: Remote system error NFS fsstat failed for server ckpc2: RPC: Remote system error bdf: /W2K.data: I/O error root@hpeos004[]
This is where CIFS and NFS have a fundamental difference; CIFS grants access on a user-by-user basis. We will need to be authenticated by the CIFS server before we can use the share.
Access to individual CIFS shares is on a user-by-user basis. Even though we have added entries to the /etc/fstab file, we will not see mounted filesystems until a user (CIFS client) is authenticated by the CIFS server. Obviously, we need to have a valid username and password configured on the CIFS server. If the CIFS server is an HP-UX machine, it is a good idea that UIDs on both machines are kept consistent so that file access permissions and ownerships work in a consistent manner.
root@hpeos004[] /opt/cifsclient/bin/cifslogin ckpc2 charlesk
Remote user charlesk's password:
Now that we are authenticated, we can see and use the shares we have access to:
root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051455 235395 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 51590 435573 11% /var /dev/vg00/lvol7 917504 753622 153675 83% /usr /dev/vg00/lvol4 65536 2237 59347 4% /tmp /dev/vg00/lvol6 851968 649867 189695 77% /opt /dev/vg00/lvol5 24576 1390 21740 6% /home ckpc2:/work 39029912 27675024 11354888 71% /W2K.data root@hpeos004[W2K.data] cd /W2K.data root@hpeos004[W2K.data] ls ACCESS Java Video AutoSketch Netscape Word Education OU courses FromHP OfficeJetG95-Software free HP-Book Perl progs HP-NetAccess PowerPoint route.print HPUX-tools Reflection tmp Images Rescued document.txt root@hpeos004[W2K.data]
There's also a command cifslist, which will show us the shares we have access to. I would like to use the command before we run cifslogin, but it doesn't work that way; you have to be authenticated before you can see what you have access to:
root@hpeos004[W2K.data] /opt/cifsclient/bin/cifslist -A
========================================================================
server ckpc2:
========================================================================
Remote Username: charlesk Local Username: root
Share: \CKPC2WORK
rw /W2K.data
root@hpeos004[W2K.data]
This is effectively the same as a net view \ckpc2 command that you could execute from a Windows-based machine.
Once a user is finished with a share, he can issue a cifslogout command to end his CIFS session. If not, the share will remain mounted. You may want to think about issuing a trap from within a user's .profile to issue a cifslogout when he exits from his UNIX session.
root@hpeos004[W2K.data] cd root@hpeos004[] /opt/cifsclient/bin/cifslogout ckpc2 root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051455 235395 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 51590 435573 11% /var /dev/vg00/lvol7 917504 753622 153675 83% /usr /dev/vg00/lvol4 65536 2237 59347 4% /tmp /dev/vg00/lvol6 851968 649867 189695 77% /opt /dev/vg00/lvol5 24576 1390 21740 6% /home NFS fsstat failed for server ckpc2: RPC: Remote system error bdf: /W2K.data: I/O error root@hpeos004[]
At this point, a user can reuse the CIFS share simply by running cifslogin. If we are completely finished with this share, we will probably want to umount the share to avoid the I/O errors from bdf. We can simply use the familiar umount command, as we would do with any other mount point. Alternately, root can use the option force_umount to the cifsclient command, although we need to shut down the CIFS client daemon (this command is normally used only if a normal umount fails) :
root@hpeos004[] /opt/cifsclient/bin/cifsclient force_umount /W2K.data The 'force_umount' command cannot be used when the CIFS Client is running. root@hpeos004[] umount /W2K.data root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051455 235395 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 51574 435588 11% /var /dev/vg00/lvol7 917504 753622 153675 83% /usr /dev/vg00/lvol4 65536 2237 59347 4% /tmp /dev/vg00/lvol6 851968 649867 189695 77% /opt /dev/vg00/lvol5 24576 1390 21740 6% /home root@hpeos004[]
There is an alternative to using /etc/fstab and cifslogin; the command I am thinking of is cifsmount. With cifsmount, we can supply all parameters necessary to log in and mount the required filesystem:
root@hpeos004[] /opt/cifsclient/bin/cifsmount //ckpc2/work /W2K.data -U charlesk -P banana11 root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051515 235339 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 51576 435585 11% /var /dev/vg00/lvol7 917504 753622 153675 83% /usr /dev/vg00/lvol4 65536 2237 59347 4% /tmp /dev/vg00/lvol6 851968 649867 189695 77% /opt /dev/vg00/lvol5 24576 1390 21740 6% /home localhost:\CKPC2WORK 39029912 27677896 11352016 71% /W2K.data root@hpeos004[]
This command and its sister command cifsumount are commonly seen in scripts used for batch job operations via cron, and so on.
First things first. If you get this configuration wrong, you might be left in a position where no one is able to log in to your HP-UX server. This is serious! Let me make it even clearer. We are still going to use the libpam_unix.1 module to authenticate “normal” UNIX users, e.g., root, bin, sys, and any other valid UNIX-only users. What this configuration will do is allow users to log in to our HP-UX servers with the passwords being authenticated on a Windows server. Remember, in order to log in to a UNIX machine, you will need to have an entry in /etc/passwd. All the entries in our password file will provide a username/UID; this is essential on UNIX so you can be identified with processes, files, and so on. The difference here is that password management is being taken care of by a Windows server, e.g., NT, 2000, and XP. Here's an example /etc/passwd file on our HP-UX CIFS client:
root@hpeos004[] cat /etc/passwd
root:HRl3bvbgAJAzY:0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
oracle::102:102:Oracle:/home/oracle:/usr/bin/sh
nobody:*:-2:-2::/:
www:*:30:1::/:
webadmin:*:40:1::/usr/obam/server/nologindir:/usr/bin/false
bonzo:w/gZ2rWgdzMuc:101:20::/home/bonzo:/sbin/sh
mikey:3VYPC9Fw4Mr/.:103:20::/home/mikey:/sbin/sh
stevo:kXWYDiSgtDims:104:20::/home/stevo:/sbin/sh
fred:*:105:20::/home/fred:/sbin/sh
barney:*:106:20::/home/barney:/sbin/sh
wilma:*:107:20::/home/wilma:/sbin/sh
betty:*:108:20::/home/betty:/sbin/sh
root@hpeos004[]
As you can see, we still have real UNIX users such as root, bonzo, mikey, and stevo; they have real UNIX passwords. We also have users with invalid passwords: fred, barney, wilma, and betty. These users need to log in to our HP-UX server, but their passwords are maintained on an NT/2000/XP server (in this case, a NT 4.0 SP6 server known as NTPDC1). Figure 20-2 shows the User Manager for Domains screen from NTPDC1:
NOTE: I have included a bogus root user on NTPDC1 to help demonstrate the necessity of being careful with the configuration files we will work with, i.e., /etc/pam.conf.
The file we are initially configuring is a file that configures the modules used to authenticate users logging in to this server: /etc/pam.conf. Normally, the login process (including passwd, su, dtlogin, ftp, and so on) will use the shared library /usr/lib/security/libpam_unix.1 to authenticate users; the pam.conf file identifies a pluggable authentication module, hence, the name. We are going to change this configuration. The change means we will authenticate users via the Windows server. This is essentially a CIFS client configuration change; we are specifying where to utilize the NTLM authentication credentials stored on the Windows server. This means that should these users wish to use a CIFS share advertised somewhere within the Windows domain, they will not have to cifslogin to that CIFS server because our HP-UX server has cached the users' security credentials obtained during the NTLM authentication with the Windows server.
In my mind, I would probably want to always authenticate real UNIX users, e.g., root, bonzo, mikey, and stevo locally on my HP-UX server; I wouldn't want to miss authenticating these important users via our Windows server. This can be the scary bit; if you don't ensure that real UNIX users are authenticated locally, you may be in a situation where root can't log in, and that's not a good thing. My configuration examples below will take this into account. Here are the steps involved:
Configure
/etc/pam.confto utilize NTLM as an authentication protocol in addition to using standard UNIX login semantics.Configure
smb.confto reference the NTLM server.Configure a user map to specifically reference individual UNIX users to a different username on the NTLM server (optional).
Restart CIFS client daemon to pick up changes in
smb.conf(only necessary if you are changing the NTLM server specifications).Test the functionality of NTLM authentication.
Here, we are ensuring that we configure NTLM as an additional authentication protocol not only when a user logs in but also when he changes his password (either of his own choice or because the password expired). This requires you to configure the Authentication, Account, and Password sections of /etc/pam.conf; you will see them clearly commented in the /etc/pam.conf file. Here is the /etc/pam.conf file I used on my CIFS client hpeos004:
root@hpeos004[] vi /etc/pam.conf
#
# PAM configuration
#
# Authentication management
#
login auth sufficient /usr/lib/security/libpam_ntlm.1 debug
login auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
su auth sufficient /usr/lib/security/libpam_ntlm.1 debug
su auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
dtlogin auth sufficient /usr/lib/security/libpam_ntlm.1 debug
dtlogin auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
dtaction auth sufficient /usr/lib/security/libpam_ntlm.1 debug
dtaction auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
ftp auth sufficient /usr/lib/security/libpam_ntlm.1 debug
ftp auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
OTHER auth required /usr/lib/security/libpam_unix.1 debug
#
# Account management
#
login account sufficient /usr/lib/security/libpam_ntlm.1 debug
login account required /usr/lib/security/libpam_unix.1 debug
su account sufficient /usr/lib/security/libpam_ntlm.1 debug
su account required /usr/lib/security/libpam_unix.1 debug
dtlogin account sufficient /usr/lib/security/libpam_ntlm.1 debug
dtlogin account required /usr/lib/security/libpam_unix.1 debug
dtaction account sufficient /usr/lib/security/libpam_ntlm.1 debug
dtaction account required /usr/lib/security/libpam_unix.1 debug
ftp account sufficient /usr/lib/security/libpam_ntlm.1 debug
ftp account required /usr/lib/security/libpam_unix.1 debug
OTHER account required /usr/lib/security/libpam_unix.1 debug
#
# Session management
#
login session required /usr/lib/security/libpam_unix.1 debug
dtlogin session required /usr/lib/security/libpam_unix.1 debug
dtaction session required /usr/lib/security/libpam_unix.1 debug
OTHER session required /usr/lib/security/libpam_unix.1 debug
#
# Password management
#
login password required /usr/lib/security/libpam_ntlm.1 debug
login password required /usr/lib/security/libpam_unix.1 debug
passwd password required /usr/lib/security/libpam_ntlm.1 debug
passwd password required /usr/lib/security/libpam_unix.1 debug
dtlogin password required /usr/lib/security/libpam_ntlm.1 debug
dtlogin password required /usr/lib/security/libpam_unix.1 debug
dtaction password required /usr/lib/security/libpam_ntlm.1 debug
dtaction password required /usr/lib/security/libpam_unix.1 debug
OTHER password required /usr/lib/security/libpam_unix.1 debug
root@hpeos004[cifsclient]
I explain some of the changes I made and take the service name of login in the Authentication module as an example:
login auth sufficient /usr/lib/security/libpam_ntlm.1 debug login auth required /usr/lib/security/libpam_unix.1 debug try_first_pass
The PAM framework allows us to stack service names in order to implement multiple authentication services. PAM will process each of the service modules in the stack as listed in the configuration file. The controlling influence over success and failure is the control flag, e.g., sufficient or required in this case. A sufficient flag means that if the module is successful, then a success is returned to the login process, assuming that any previous required modules have been successful as well. The debug option will send a message to syslog at the debug level (we will configure syslog to capture this). The try_first_pass option will use the password entered when the first module in the stack authenticated the user. Here are a few examples:
In our example, if
mikeytries to log in, we attempt to authenticate him via the Windows server using the password he enters. This will fail, and we attempt to authenticate him using the same password but against/etc/passwd. If this succeeds, he will be allowed to log in.If
fredtries to log in, he will be authenticated by the NT server and that will be sufficient to allow him to log in. Iffredthen tries tosutomikey, he will need to supply the correct password formikey. This password will be authenticated first by the Windows server and will fail. Because we have used thetry_first_passoption, the passwordfredsupplied will be passed tolibpam_unix.1. If he supplied the correct password, he will be allowed tosuwith no further prompts. Iffredsupplied the wrong password (or we didn't use thetry_first_passoption),fredwill be asked to enter the password formikeyvia aSystem Password:prompt.If we take
rootas an example, this becomes more interesting. Whenrootlogs in, it will be authenticated by the NT server (remember, we added a bogusrootaccount). In this instance, we have entered the UNIX password; the authentication on the Windows server will fail (unless the password on both servers happens to be the same). In this instance,rootwill be logged in because we use thetry_first_passoption. If we had entered a completely wrong password, we would be prompted by thelibpam_unix.1module to re-enter the password via aSystem Password:prompt. This may be a surprise to some administrators; this is the functionality oflibpam_unix.1; readman pam_unix! The other point to make about having a bogusrootaccount is when we change therootpassword. Because we will use the NTLM module, first we will be asked for the oldrootpassword, because this is the protocol under Windows; this should prompt suspicion in the mind of arootuser (unless we are running in a Trusted System). If you successfully supply the correct old password, you will then have an opportunity to change the password on the Windows Server. If you do not supply the correct old password, you will then fall through to use the UNIX semantics whereby you are not asked for an old password (unless in Trusted Systems). Finally, if we were to enter the correct password for therootaccount as stored on the Windows server, we will be allowed to log in. Some people may view this as a potential security problem with a second source potentially authenticating therootuser. Utilizing separate, site-wide username and password policies for both platforms would help to alleviate this problem. Having passwords synchronized (or not, as the case may be) between platforms is another possible solution and is a topic beyond the scope of this chapter. This is worth remembering.
Because this is somewhat involved, we will go through a number of examples once we conclude the configuration.
Here, we need to change the client version of the smb.conf file to use domain level security that, in turn, requires us to configure the name of the password servers as well as a WINS server within our Windows domain. Here are the changes I made to the CIFS client smb.conf file to implement this new configuration:
root@hpeos004[] vi /etc/opt/cifsclient/pam/smb.conf ... [global] ## workgroup: NT-Domain-Name or Workgroup-Name workgroup = UKDOM1 ## password server: the netbios names of systems which will ## be used to authenticate logins. password server = NTPDC1 ## wins server: the system used to locate password servers, ## specified as a fully-qualified DNS name or an IP address. wins server = NTPDC1
This step is optional. What the user map allows us to configure is a list of UNIX users who will have their passwords stored on the Windows server as before, but potentially under a different username. First, we configure the name of the file that maps the UNIX username to the Windows domain username; we accomplish this in the smb.conf file. We then construct the file that individually lists the UNIX-to-Windows username map.
root@hpeos004[] vi /etc/opt/cifsclient/pam/smb.conf [Global] Domain user map = /etc/opt/cifsclient/pam/domain_user.map root@hpeos004[] vi /etc/opt/cifsclient/pam/domain_user.map barney = \UKDOM1ambam
Once we have made these necessary changes, it may be necessary to restart the cifsclientd daemon if we have changed any of the server specifications. If we have made only minor changes, we do not need to restart the daemon. We can simply use the clifsclient command to restart the cifsclientd process (NOTE: This will unmount all CIFS shares in the process of restarting the daemon):
root@hpeos004[] cifsclient restart
We perform a number of tests to ensure that all is working as expected. First, I need to configure syslog to capture the debug messages from the authentication subsystem; this does not happen by default. To make my life a little easier, I will separate out all authentication facility messages at the debug level or higher to a separate file from syslog.log:
root@hpeos004[] vi /etc/syslog.conf # @(#)B.11.11_LR # # syslogd configuration file. # # See syslogd(1M) for information about the format of this file. # mail.debug /var/adm/syslog/mail.log *.info;mail.none /var/adm/syslog/syslog.log auth.debug /var/adm/syslog/pam_debug.log *.alert /dev/console *.alert root *.emerg * root@hpeos004[] root@hpeos004[] kill -HUP $(cat /var/run/syslog.pid) root@hpeos004[] ll /var/adm/syslog total 132 -rw-r--r-- 1 root root 11067 Sep 9 18:31 OLDsyslog.log -r--r--r-- 1 root root 0 Sep 10 14:50 auth_debug.log -r--r--r-- 1 root root 27914 Sep 10 09:08 mail.log -rw-r--r-- 1 root root 18806 Sep 10 14:50 syslog.log root@hpeos004[]
Let's start by ensuring that
rootcan still log in using the HP-UX password = banana11. The password forrootstored on the Windows server is root. I will include extracts from theauth_debug.logfile.root@hpeos004[] pwget -n root root:StW2t72yybduI:0:3::/:/sbin/sh root@hpeos004[] telnet hpeos004 Trying... Connected to hpeos004. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON HP-UX hpeos004 B.11.11 U 9000/800 (ta) login: root Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). You have mail. Value of TERM has been set to "dtterm". WARNING: YOU ARE SUPERUSER !! root@hpeos004[]
Here is the extract from the auth_debug.log file:
Sep 10 10:04:22 hpeos004 login: Entering ntlm pam_sm_authenticate: flags 0 Sep 10 10:04:22 hpeos004 login: ntlm pam_sm_authenticate(login, root), flags = 0 Sep 10 10:04:28 hpeos004 login: pam_ntlm: Incorrect NT password for username : root Sep 10 10:04:28 hpeos004 login: ntlm authentication failed! Bad Password Sep 10 10:04:28 hpeos004 login: ntlm_pam_authenticate: returning FAILURE Sep 10 10:04:28 hpeos004 login: pam_authenticate: error Authentication failed Sep 10 10:04:28 hpeos004 login: unix pam_sm_authenticate(login root), flags = 0 Sep 10 10:04:28 hpeos004 login: Entering ntlm pam_sm_acct_mgmt: flags 0 Sep 10 10:04:28 hpeos004 login: nltm pam_sm_acct_mgmt pam_get_data err=24 Sep 10 10:04:28 hpeos004 login: pam_acct_mgmt: error No account present for user Sep 10 10:04:28 hpeos004 login: Entering ntlm pam_sm_setcred ... Sep 10 10:04:28 hpeos004 login: pam_sm_setcred(): no module data
The first thing I should point out is the slight delay you may experience while the authentication takes place. Normally, standard UNIX authentication is almost instantaneous. In this case, there was a perceived delay of approximately 0.5-1 second. Let's get back to the output from auth_debug.log. The first six lines highlight the attempt to authenticate root using the password banana11; this fails. We then see the UNIX authentication succeed. Finally, we see the Windows server trying to perform Account Management tasks for this user; that fails also.
We will try to log in as
fred; remember,fredhas an invalid password as far as HP-UX is concerned (fred's password on the Windows Server happens to be fred).root@hpeos004[] pwget -n fred fred:*:105:20::/home/fred:/sbin/sh root@hpeos004[] telnet hpeos004 Trying... Connected to hpeos004. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON HP-UX hpeos004 B.11.11 U 9000/800 (ta) login: fred Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). $ id uid=105(fred) gid=20(users) $
Here's the accompanying output from auth_debug.log:
Sep 10 10:12:00 hpeos004 login: Entering ntlm pam_sm_authenticate: flags 0 Sep 10 10:12:00 hpeos004 login: ntlm pam_sm_authenticate(login, fred), flags = 0 Sep 10 10:12:02 hpeos004 login: pam_ntlm: fred Succesfully logged is as fred Sep 10 10:12:02 hpeos004 login: ntlm authenticate passed! Sep 10 10:12:02 hpeos004 login: setCred succeed for fred, uid 105, size 260; Sep 10 10:12:02 hpeos004 login: ntlm_pam_authenticate: returning SUCCESS Sep 10 10:12:02 hpeos004 login: Entering ntlm pam_sm_acct_mgmt: flags 0 Sep 10 10:12:02 hpeos004 login: Entering ntlm pam_sm_setcred ... Sep 10 10:12:02 hpeos004 login: pam_sm_setcred(): no module data
As we can see, fred is authenticated by the Windows Server.
We will log in as
mikeyand ensure that we can change to another valid UNIX account (use thesucommand), in this case the userstevo.root@hpeos004[] pwget -n mikey mikey:3VYPC9Fw4Mr/.:103:20::/home/mikey:/sbin/sh root@hpeos004[] pwget -n stevo stevo:kXWYDiSgtDims:104:20::/home/stevo:/sbin/sh root@hpeos004[] telnet hpeos004 Trying... Connected to hpeos004. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON HP-UX hpeos004 B.11.11 U 9000/800 (ta) login: mikey Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). $ su - stevo Password: (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). $ id uid=104(stevo) gid=20(users) $
Again, it is worthwhile to check the debug output from auth_debug.log to ensure that all is working as expected:
Sep 10 10:17:12 hpeos004 login: Entering ntlm pam_sm_authenticate: flags 0 Sep 10 10:17:12 hpeos004 login: ntlm pam_sm_authenticate(login, mikey), flags = 0 Sep 10 10:17:17 hpeos004 login: pam_ntlm: Incorrect NT password for username : mikey Sep 10 10:17:17 hpeos004 login: ntlm authentication failed! Bad Password Sep 10 10:17:17 hpeos004 login: ntlm_pam_authenticate: returning FAILURE Sep 10 10:17:17 hpeos004 login: pam_authenticate: error Authentication failed Sep 10 10:17:17 hpeos004 login: unix pam_sm_authenticate(login mikey), flags = 0 Sep 10 10:17:17 hpeos004 login: Entering ntlm pam_sm_acct_mgmt: flags 0 Sep 10 10:17:17 hpeos004 login: nltm pam_sm_acct_mgmt pam_get_data err=24 Sep 10 10:17:17 hpeos004 login: pam_acct_mgmt: error No account present for user Sep 10 10:17:17 hpeos004 login: Entering ntlm pam_sm_setcred ... Sep 10 15:17:24 hpeos004 su: Entering ntlm pam_sm_authenticate: flags 0 Sep 10 15:17:24 hpeos004 su: ntlm pam_sm_authenticate(su, stevo), flags = 0 Sep 10 15:17:30 hpeos004 su: pam_ntlm: Incorrect NT password for username : stevo Sep 10 15:17:30 hpeos004 su: ntlm authentication failed! Bad Password Sep 10 15:17:30 hpeos004 su: ntlm_pam_authenticate: returning FAILURE Sep 10 15:17:30 hpeos004 su: pam_authenticate: error Authentication failed Sep 10 15:17:30 hpeos004 su: unix pam_sm_authenticate(su stevo), flags = 0 Sep 10 15:17:30 hpeos004 su: Entering ntlm pam_sm_acct_mgmt: flags 0 Sep 10 15:17:30 hpeos004 su: nltm pam_sm_acct_mgmt pam_get_data err=24 Sep 10 15:17:30 hpeos004 su: pam_acct_mgmt: error No account present for user Sep 10 15:17:30 hpeos004 su: Entering ntlm pam_sm_setcred ... Sep 10 15:17:30 hpeos004 su: + ta mikey-stevo
Again, we see that both the login and su processes will try to authenticate the user on the Windows server; it will fail and then authenticate them on the HP-UX server.
Here, we will demonstrate the problems of having duplicate accounts on both the Windows and HP-UX servers, namely the potential problem with the
rootuser. You will recall that therootuser on the Windows server has a password ofroot, and on the HP-UX server it has a password ofbanana11. We will accidentally enter a completely wrong password. We should see thatlibpam_ntlm.1fails to authenticate us; the password is passed tolib_pam.unix.1(via thetry_first_passoption), but this fails andlibpam_unix.1should issue a prompt ofSystem Password:to enable us to enter the real UNIXrootpassword. Let's see what happens:root@hpeos004[] telnet hpeos004 Trying... Connected to hpeos004. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON HP-UX hpeos004 B.11.11 U 9000/800 (ta) login: root Password: → garbage password entered! System Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). You have mail. Value of TERM has been set to "dtterm". WARNING: YOU ARE SUPERUSER !! root@hpeos004[]
Here is the output from auth_debug.log:
Sep 10 13:00:39 hpeos004 login: Entering ntlm pam_sm_authenticate: flags 0 Sep 10 13:00:39 hpeos004 login: ntlm pam_sm_authenticate(login, root), flags = 0 Sep 10 13:00:45 hpeos004 login: pam_ntlm: Incorrect NT password for username : root Sep 10 13:00:45 hpeos004 login: ntlm authentication failed! Bad Password Sep 10 13:00:45 hpeos004 login: ntlm_pam_authenticate: returning FAILURE Sep 10 13:00:45 hpeos004 login: pam_authenticate: error Authentication failed Sep 10 13:00:45 hpeos004 login: unix pam_sm_authenticate(login root), flags = 0 Sep 10 13:00:55 hpeos004 login: Entering ntlm pam_sm_acct_mgmt: flags 0 Sep 10 13:00:55 hpeos004 login: nltm pam_sm_acct_mgmt pam_get_data err=24 Sep 10 13:00:55 hpeos004 login: pam_acct_mgmt: error No account present for user Sep 10 13:00:55 hpeos004 login: Entering ntlm pam_sm_setcred ... Sep 10 13:00:55 hpeos004 login: pam_sm_setcred(): no module data
The last test is to demonstrate the use of a share from the NTPDC1 server. We add an entry in the
/etc/fstabfile. We log in as the userfredand see if we can use the share without using thecifslogincommand or having to provide a password to thecifsmountcommand. Here goes:root@hpeos004[] echo "ntpdc1:/data /data cifs defaults 0 0" >> /etc/fstab root@hpeos004[] mount -aF cifs root@hpeos004[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051972 234905 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 87107 402251 18% /var /dev/vg00/lvol7 917504 755385 152046 83% /usr /dev/vg00/lvol4 204800 113745 85371 57% /tmp /dev/vg00/lvol6 851968 649868 189694 77% /opt /dev/vg00/lvol5 24576 1650 21542 7% /home NFS access failed for server ntpdc1: RPC: Remote system error NFS fsstat failed for server ntpdc1: RPC: Remote system error bdf: /data: I/O error root@hpeos004[] telnet hpeos004 Trying... Connected to hpeos004. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON HP-UX hpeos004 B.11.11 U 9000/800 (ta) login: fred Password: Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). $ cd /data $ ll total 5482 drwxrwxrwx 2 fred users 131072 Sep 10 10:14 HP-NetAccess drwxrwxrwx 2 fred users 131072 Sep 10 10:15 HPUX-tools -rwxrwxrwx 1 fred users 2806496 Sep 10 11:56 NT-users.tif drwxrwxrwx 2 fred users 131072 Sep 10 10:15 Netscape drwxrwxrwx 2 fred users 131072 Sep 10 10:14 OfficeJetG95-Software drwxrwxrwx 2 fred users 131072 Sep 10 10:20 free drwxrwxrwx 2 fred users 131072 Sep 10 10:16 progs $ bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051972 234905 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 87233 402133 18% /var /dev/vg00/lvol7 917504 755385 152046 83% /usr /dev/vg00/lvol4 204800 113745 85371 57% /tmp /dev/vg00/lvol6 851968 649868 189694 77% /opt /dev/vg00/lvol5 24576 1650 21542 7% /home NFS access failed for server ntpdc1: RPC: Remote system error NFS fsstat failed for server ntpdc1: RPC: Remote system error bdf: /data: I/O error $ touch fred.file $ ll total 5482 drwxrwxrwx 2 fred users 131072 Sep 10 10:14 HP-NetAccess drwxrwxrwx 2 fred users 131072 Sep 10 10:15 HPUX-tools -rwxrwxrwx 1 fred users 2806496 Sep 10 11:56 NT-users.tif drwxrwxrwx 2 fred users 131072 Sep 10 10:15 Netscape drwxrwxrwx 2 fred users 131072 Sep 10 10:14 OfficeJetG95-Software -rwxrwxrwx 1 fred users 0 Sep 10 15:27 fred.file drwxrwxrwx 2 fred users 131072 Sep 10 10:20 free drwxrwxrwx 2 fred users 131072 Sep 10 10:16 progs $ bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1302528 1051972 234905 82% / /dev/vg00/lvol1 111637 49319 51154 49% /stand /dev/vg00/lvol8 516096 87233 402133 18% /var /dev/vg00/lvol7 917504 755385 152046 83% /usr /dev/vg00/lvol4 204800 113745 85371 57% /tmp /dev/vg00/lvol6 851968 649868 189694 77% /opt /dev/vg00/lvol5 24576 1650 21542 7% /home NFS access failed for server ntpdc1: RPC: Remote system error NFS fsstat failed for server ntpdc1: RPC: Remote system error bdf: /data: I/O error $
As we can see, we are free to use the filesystem because the Windows server has authenticated us. Those credentials are used every time we wish to use the share; the bdf command is not actually using the share itself. Anyone trying to use the share will have his credentials checked in a similar way; next, we can see root trying to access the share with fred still logged in:
root@hpeos004[] cd /data NFS access failed for server ntpdc1: RPC: Remote system error sh: /data: The specified directory is not valid. root@hpeos004[] who root pts/0 Sep 10 09:32 root pts/1 Sep 10 09:32 root pts/2 Sep 10 09:32 fred pts/ta Sep 10 15:32 root pts/3 Sep 10 10:41 root@hpeos004[]
As you can see, the credentials don't allow access to anyone not already authenticated.
This concludes the chapter on CIFS/9000. We have looked at a number of configuration possibilities from setting up a CIFS server and client, and we looked at using NTLM and a Windows-based server to authenticate our users. The topic of SAMB, CIFS, SMB—whatever you want to call it—is getting bigger, with more and more sites building heterogeneous networks of UNIX and Windows servers providing data to an ever-increasing user-base. The Web site that maintains the most up-to-date SAMBA information and Open Source releases is http://www.samba.org. This Web site and HP's software depot (http://software.hp.com) are worth keeping an eye on to stay up to date with developments in the area of CIFS.