It’s useful and easy to debug on SuSE as compared to setting up to do this on Solaris or elsewhere. Solaris supports pam.conf rather than the DIRMODE pam.d of Linux. Still, the following steps trick vastool into working against the file rather than the directory configuration files:
At this point, vastool can be debugged using one of the root shells since anything vastool operation involving pam.conf implies root privileges. Once finished, perform these remaining steps:
Note, for example, that Solaris doesn’t support *.* in syslog. PAM logs to the auth facility though so auth.debug works on all platforms.
SuSE 10 (and certainly many earlier versions) doesn’t use the antiquated /etc/pam.conf in its PAM implementation. Under its /etc/pam.d subdirectory, however, are a number of “common” files (corresponding, obviously, to PAM operations).
common-account common-auth common-password common-session
In place of longer lines in each of the configuration files, one or more of these common files can be found. Thus, sshd has
auth include common-auth auth required pam_nologin.so account include common-account password include common-password session include common-session
...and in common-auth, for example, one finds
auth required pam_env.so auth [ignore=ignore success=done default=die] pam_vas3.so get_tgt auth requires pam_unix2.so
To debug something as it goes through PAM (either using an AD user or root), it is only necessary to add debug trace after white space at the end of the line (of any of these common files) containing pam_vas3.so.
Syntax of an entry in the pam.conf file...
<service-name> <module-type> <control-flag> <module-path> <args>
corresponding to, for example,
login auth required /usr/lib/security/$ISA/pam_unix.so.1 first_pass debug
Of course, to run gdb or ddd to debug the PAM module is damn nigh impossible.
PAM documentation links...
...and your screensaver came and locked the screen or the building lost power. (I run the grub loader; I don’t know what to do for lilo.) Reboot and when the opportunity arises, press F2 as indicated for “more options.” This gives you the loader command line. Append the following to it:
init=/bin/bash
And continue on. It will come up in bash, you can restore PAM to its pristine state. In the case of VAS (all we’re thinking about here anyway), merely edit /etc/pam.d/common-* and remove all the lines containing the VAS PAM stuff, “pam_vas3.so.” Also, in common-auth, the mention “use_first_pass” must be removed from the line on which it is found.
After taking care of these PAM files, resync, and reboot. The inability to authenticate should be fixed although VAS will have to be configured again:
vastool configure pam
It’s best to keep console 1 logged in as root so that ctrl alt F1 will get you into it whence you can fix your PAM files. ctrl alt F7 will get you back into your GUI.
It’s possible to include files in a PAM configuration file. This happens two ways.
include filename
...includes filename in the PAM file at that point. This approach might be a little more common in the case of /etc/pam.conf implementations. (I don’t know for sure.)
Here, however, is PAM file /etc/pam.d/sshd on SuSE Linux 10.2:
#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session auth include common-auth # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README) #session optional pam_resmgr.so fake_ttyname
In this case, inclusion works the same, but essentially replaces the whole line it’s on with the file. Thus, after the first inclusion shown here in red, for authentication, this file becomes as follows. Note that our VAS annotation is present since it’s in /etc/pam.d/common-auth.
#%PAM-1.0 auth requisite pam_nologin.so #%PAM-1.0 # # This file is autogenerated by pam-config. All changes # will be overwritten. # # Authentication-related modules common to all services # # This file is included from other service-specific PAM confg files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.e., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # auth sufficient pam_vas3.so create_homdir get_nonvas_pass debug trace auth requisite pam_vas3.so echo_return auth required pam_unix2.so use_first_pass account include common-account password include common-password session required pam_loginuid.so session include common-session auth include common-auth # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README) #session optional pam_resmgr.so fake_ttyname
On SuSE Linux, /etc/pam.d/common-account, -auth, -password and -session contain the common elements for those PAM task types. On Red Hat, the same objective is achieved by the file /etc/pam.d/sys-auth. There is nothing magic about these files and any name could be used by hand-crafting, but the operating systems create those files automatically at first.
To muck around with Active Directory in test domains such as a.vas, through tests and using rdesktop, /etc/resolv.conf must be changed—destructively—to accommodate. Originally, this file contained:
domain vintela.com nameserver 10.5.33.1 nameserver 10.5.33.2
...and must be modified to:
search vintela.com vas test.vintela.com #nameserver 192.168.131.1 nameserver 10.5.33.1 nameserver 10.5.33.2
For testing purposes, make it:
search vintela.com vas test.vintela.com nameserver 192.168.131.1 #nameserver 10.5.33.1 #nameserver 10.5.33.2
One way of doing this would be to create a script(*) to rename and copy versions of this file around, resolv.sh normal and resolv.sh test (nothing significant in this script name). Remember too:
rdesktop -u administrator -p test123 a.vas
Does the fact that one can rdesktop in and find a user also mean that a test can make use of that user? It should, but it doesn’t. The host must be joined to the test domain in order for vas_id_alloc and vas_ctx_alloc to embed a.vas instead of the usual vintela.com inside. The process is thus destructive of two host states:
The solution therefore to the second problem is to join the host temporarily to the test domain:
vastool -u administrator -w test123 join -f a.vas
To return to the productive (or default) state, see vastool join work below: the “my real one” command.
Because of having to change frequently, as of 5 March 2006, I divided resolv.conf into three and a script, resolv.sh, with commands normal, test and dev in order to consume the domain made available through server schizo (see discussion of this server elsewhere):
search dev vintela.com nameserver 192.168.144.5
What the heck, here is the script...
#!/bin/sh # This sets up /etc/resolv.conf to be suitable for mucking about in the Vintela # testing domains. Must be run as root, obviously. if [ $EUID != 0 ]; then echo " Must be root to do this!" echo " resolv.sh [normal|test|dev]" cat /etc/resolv.conf elif [ "$1" == "normal" ]; then if [-f "/etc/resolv.conf.orig" ]; then rm /etc/resolv.conf cp /etc/resolv.conf.orig /etc/resolv.conf cat /etc/resolv.conf else echo "No resolv.conf.orig to start with..." fi elif [ "$1" == "test" ]; then if [-f "/etc/resolv.conf.test" ]; then rm /etc/resolv.conf cp /etc/resolv.conf.test /etc/resolv.conf cat /etc/resolv.conf echo "" echo " Reminder: rdesktop -u administrator -p test123 a.vas" else echo "No resolv.conf.test to start with..." fi elif [ "$1" == "dev" ]; then if [-f "/etc/resolv.conf.dev" ]; then rm /etc/resolv.conf cp /etc/resolv.conf.dev /etc/resolv.conf cat /etc/resolv.conf echo "" echo " Reminder: vmware-console [administrator password is Test1234 a.dev]" else echo "No resolv.conf.dev to start with..." fi fi # vim: set tabstop=2 shiftwidth=2 expandtab:
...and here are the three files, all on /etc:
resolv.conf.orig: domain vintela.com nameserver 10.5.33.1 nameserver 10.5.33.2 resolv.conf.test: search test.vintela.com vas vintela.com nameserver 192.168.131.1 resolv.conf.dev: search dev vas vintela.com nameserver 192.168.144.5