10-08-2013 01:57 PM - last edited on 10-08-2013 10:32 PM by maikoro
I am trying to set up a new ia64 hp server rx1620 that my company has recently purchased. We develop and distribute a remote access product for various UNIX systems including HP-UX, but until now have always worked on HP-UX 11.11 and 11.23 systems -- this is our first 11.31 system.
After installing our product on the system, I'm unable to remotely authenticate, receiving an error code of 13 from the call to pam_authenticate(). I'm fairly sure that our PAM code is correct as it works on other HP-UX versions as well as Linux and Solaris (and apparently works for our customers on 11.31 as well).
I've installed the HP sshd and it is able to authenticate without difficulty. I have tried various manipulations of the /etc/pam.conf file to no avail, including adding debug options and configuring syslog.conf to capture debug output but all that is logged is:
Oct 8 16:50:59 hpux1131a custom: pam_authenticate: error No account presen
t for user
I've tried running tusc on my server process to see what the pam modules are trying to do, but all I see is:
 write(4, 0x60000000000c0f88, 92) ................. = 92
( t : 1 ) ( m a s t e r ) [ 0 8 O c t 1 6 : 5 2 : 4 7 ]
: l e a d e r [ 7 ] : p a m - l o g i n : P a m C o n v e r
s a t i o n H a n d l e r r e s p o n s e = d e m o \n
 getpid() ......................................... = 12441 (12425)
 stat("/tcb/files/auth/system/default", 0x9fffffffffff8040) ERR#2 ENOENT
 getdomainname("", 256) ........................... = 0
 access("/etc/default/DISABLE_PAM_DELAY", F_OK) ... ERR#2 ENOENT
(t:1) (master) [08 Oct 16:52:47]: leader: pam-login:PamConversationHandler response=demo
 nanosleep2(0x9fffffffffffe710, 0x9fffffffffffe720) [sleeping]
 nanosleep2(0x9fffffffffffe710, 0x9fffffffffffe720) = 0
 time(NULL) ....................................... = 1381265569
date: Tue Oct 8 16:52:49 2013
 write(4, 0x60000000000c0f88, 85) ................. = 85
( t : 1 ) ( m a s t e r ) [ 0 8 O c t 1 6 : 5 2 : 4 9 ]
: l e a d e r [ 6 ] : p a m - l o g i n : p a m _ a u t h
e n t i c a t e r e t u r n e d 1 3 \n
That it's checking for /tcb/files/auth/system/default made me wonder if it was in so-called "Trusted Mode" but it doesn't appear to be:
-bash-4.2# /usr/lbin/getprpw -l
System is not trusted.
Any suggestions would be very appreciated. I'm about at the end of my rope.
P.S. This thread has been moved from HP-UX > Languages and Scripting to HP-UX > security. - Hp Forum moderator
10-08-2013 02:13 PM
Does your product rely on the system being in trusted mode? Are your 11.11 and 11.23 systems in trusted mode?
What happens if you convert this sytem to trusted? Does it work then? Do you happen to be using /etc/shadow on the 11.31 system?
10-08-2013 03:30 PM
> Does your product rely on the system being in trusted mode?
It does not rely on trusted mode but has been tested against it (years ago).
> Are your 11.11 and 11.23 systems in trusted mode?
They are not, but the 11.11 systems have been switched between them for the purposes of development and testing of trusted mode.
> What happens if you convert this sytem to trusted? Does it work then?
I can't convert it to trusted mode while shadow passwords are in use. I got that far and stopped, not sure that this was a fruitful path to follow. I could try to pwunconv, and then tsconvert, if you think it might be useful.
> Do you happen to be using /etc/shadow on the 11.31 system?
I think so. /etc/shadow does exist and seems to be populated; creating a new user with useradd adds entries to both /etc/passwd and /etc/shadow. pwck reports no problems:
-bash-4.2# pwck -l
System is not in trusted mode
-bash-4.2# pwck -s
Checking protected database password files...
authck: cannot open Protected Password hierarchy.
10-09-2013 11:56 PM
> That it's checking for /tcb/files/auth/system/default made me wonder if it was in so-called "Trusted Mode"[...]
Actually, checking for the existence of this file *is* the official way to determine whether or not the system is in Trusted Mode.
Technically, programs are supposed to use iscomsec(2) for that... but "man 2 iscomsec" tells us that checking this file is how iscomsec() does its job:
---- quote ----
iscomsec determines if the system is a trusted system or not by checking the file, /tcb/files/auth/system/default. If the file exists, then the system is a trusted system. If the file does not exist, then the system is not a trusted system.
On a trusted system, /tcb/files/auth/system/default should never be deleted.
---- end quote ----