vendor software user authentication problem

[John Kittel]

We have some new-ish software from a vendor. It archives oracle data. I don't understand it. I'm just installing it and configuring it for our DBA. In a sandbox system. HP-UX 11.11, trusted, patched up to current. Plus a bunch of stuff on a Windows system.

There's a problem when using the vendor's software. They haven't been able to figure it out yet. When a user, on a pc, tries to get started doing something, looking at some archived data, or defining some data to be archived, one of the first things that happens is a user authentication on the HP_UX system. The authentication is failing. They say their software relies on standard HP-UX authentication for users. Attempting to figure this out, I put tusc on their process. The trace has lines indicating the code is interrogating the tcb.

But here's the weird thing that my question is about. The trace shows the code is looking for a file, /tcb/files/auth/Z/Zuser-t . But there is no user in our system named "Zuser-t". The userid of the account that installed the software and that is being used to try to use the product is "Zuser". And, the vendor claims there is no way that their software is tacking on the "-t" to the end of the user name. They are suggesting HP-UX is doing that. Which I don't believe. But here we are.

I don't see the string Zuser-t anywhere in any file on the system, including syslog.log and /var/adm/btmp.

Is there a way, other than the tusc trace I've already done, to see what the vendor's software is passing to HP-UX authentication? Is it possible HP-UX trying to stat the file /tcb/files/auth/Z/Zuser-t is just a red herring? Maybe that's somehow normal hp-ux behavior? Or is it possible there is a bug in hpux authentication whereby "-t" is arbitrarily appended to a userid string that it is going to try to authenticate? Or must it be the vendor's software passing that to hp-ux?

Here is the relevant section from the trace:

open("/etc/passwd", O_RDONLY, 0666) ...................... = 34
ioctl(34, TCGETA, 0x7800b5d8) ............................ ERR#25 ENOTTY
read(34, "r o o t : * : 0 : 3 : : / r o o ".., 8192) ..... = 8192
lseek(34, 4294962680, SEEK_CUR) .......................... = 3576
close(34) ................................................ = 0
stat("/tcb/files/auth/Z/Zuser-t", 0x7800b300) ............ ERR#13 EACCES
open("/tcb/files/auth/Z/Zuser", O_RDONLY, 0666) .......... ERR#13 EACCES


Thanks.

[Denver Osborn · Accepted solution]

John,

It's normal for it to check for Zuser-t file. The "user-t" file would lock the account. It doesn't exist.

What's the output of /usr/lbin/getprpw -l Zuser

-denver

[John Kittel]

Thank you.

I believe you, but, unexperienced and ignorant as I am about this, it leads me to the question, - since there is already a field or several fields regarding lock out status in the regular file in the tcb by the account name Zuser, what is the need of another file with -t appended to the name for lockout? Rhetorical question, I don't really need to know, just seems unnecessary, but I trust there is a reasonable explanation.

Anyway, onward with the problem at hand...

# /usr/lbin/getprpw Zuser
uid=527, bootpw=NO, audid=1318, audflg=1, mintm=-1, maxpwln=-1, exptm=-1, lftm=-
1, spwchg=Mon Nov 13 14:57:35 2006, upwchg=-1, acctexp=-1, llog=-1, expwarn=-1,
usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, admnum=-1, syschpw=DFT, sysltp
w=DFT, timeod=-1, slogint=Fri Jan 19 10:33:09 2007, ulogint=Thu Jan 4 15:47:56
2007, sloginy=pts/tb, culogin=-1, uloginy=pts/tc, umaxlntr=-1, alock=NO, lockout
=0000000

[John Kittel]

well, I guess I did have a teensy little doubt about the explanation for the -t, because I did some checking, and this would seem to disprove that explanation, here is a locked out account with no -t file:

root /root # /usr/lbin/getprpw tr19630
uid=1000, bootpw=NO, audid=31, audflg=1, mintm=-1, maxpwln=-1, exptm=-1, lftm=-1, spwchg=Thu Dec 21 14:47:04 2006, upwchg=Fri Sep 22 10:57:24 2006, acctexp=-1, llog=-1, expwarn=-1, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Thu Dec 21 14:47:11 2006, ulogint =Fri Jan 19 12:06:37 2007, sloginy=-1, culogin=3, uloginy=pts/tf, umaxlntr=-1, a
lock=NO, lockout=0001000

root /root # find /tcb/files/auth -type f -name "*-t" -print

root /root # ll /tcb/files/auth/t/tr19630*
-rw-rw-r-- 1 root root 285 Jan 19 12:06 /tcb/files/auth/t/tr19630

[Denver Osborn]

the lock file is another mechanism which could lockout an account or terminal. Sorry I can't explain it much better than that, it's just a bit of info I remember from back in the day. :)

Try it for yourself.

touch /tcb/files/auth/y/youraccount-t

You won't be able to login until the lock file is removed.

We're getting off topic too. :)

Maybe attaching more of the tusc output would help. Curious to see what is captured after open("/tcb/files/auth/Z/Zuser"

-denver

[John Kittel]

Thank you for satisfying my curiosity.

The entire trace file is huge, and I was reluctant to attach the whole thing without "sanitizing" it ( maybe it doesn't really need it, but for one thing, just in the part I posted already, I altered the actual user name while retaining the critical problem information, because it contained part of the vendor's name and I didn't want to say anything to identify them them. I don't even know if there's anything else in there that might benefit from being sanitized.)

Anyway, attached is a little more of the trace.

[Denver Osborn]

Is this a nis+ client?

Can you also post the passwd entry from /etc/nsswitch.conf file?

If it's nis+ and trusted, problem might be from having "compat" mode in nsswitch.conf for passwd.

-denver

[Heironimus]

It's getting "EACCES" (access denied) when it tries to open Zuser. Is it running as a normal user? Only root can open the tcb files.

[John Kittel]

We are not using NIS anywhere at our site, and there is no /etc/nssswitch.conf file.

[John Kittel]

regarding the question, "It's getting "EACCES" (access denied) when it tries to open Zuser. Is it running as a normal user? " ...

The vendor's daemon is not running as root. It is running as Zuser. Anyway, I think the trace shows it is trying to open in read-only mode, and the tcb file is world readable.

[Denver Osborn]

Then the only other thing I can think to look at is the /etc/pam.conf and /etc/pam_user.conf.

pam_authenticate is possibly returning error "No account present for user" which causes the login to fail.

Is it ok to post the pam.conf and pam_user.conf?

-denver

[John Kittel]

root /root # cat /etc/pam.conf
#
# PAM Configuration
#
# Account Management
#
dtaction account required /usr/lib/security/libpam_unix.1
dtlogin account required /usr/lib/security/libpam_unix.1
ftp account required /usr/lib/security/libpam_unix.1
login account required /usr/lib/security/libpam_unix.1
su account required /usr/lib/security/libpam_unix.1
rt4s account required /usr/lib/security/libpam_unix.1
OTHER account required /usr/lib/security/libpam_unix.1
#
# Authentication Management
#
dtaction auth required /usr/lib/security/libpam_unix.1
dtlogin auth required /usr/lib/security/libpam_unix.1
ftp auth required /usr/lib/security/libpam_unix.1
login auth required /usr/lib/security/libpam_unix.1
su auth required /usr/lib/security/libpam_unix.1
rt4s auth required /usr/lib/security/libpam_unix.1
OTHER auth required /usr/lib/security/libpam_unix.1
#
# Password Management
#
dtaction password required /usr/lib/security/libpam_unix.1
dtlogin password required /usr/lib/security/libpam_unix.1
login password required /usr/lib/security/libpam_unix.1
passwd password required /usr/lib/security/libpam_unix.1
OTHER password required /usr/lib/security/libpam_unix.1
#
# Session Management
#
dtaction session required /usr/lib/security/libpam_unix.1
dtlogin session required /usr/lib/security/libpam_unix.1
login session required /usr/lib/security/libpam_unix.1
OTHER session required /usr/lib/security/libpam_unix.1


root /root # cat /etc/pam_user.conf
#
# This file defines PAM configuration for a user. The configuration
# here overrides pam.conf.
#
# The format for each entry is:
# user_name module_type module_path options
#
# For example:
#
# user_a auth /usr/lib/security/libpam_unix.1 debug
# user_a auth /usr/lib/security/libpam_dce.1 try_first_pass
# user_a password /usr/lib/security/libpam_unix.1 debug
#
# user_b auth /usr/lib/security/libpam_unix.1 debug use_psd
# user_b password /usr/lib/security/libpam_unix.1 debug use_psd
#
# See the pam_user.conf(4) manual page for more information
#

[Heironimus]

On my 11.11 trusted systems the user file itself is world readable, but the directory (/tcb/files/auth/Z in your case) is 770, owned by root:sys. Normal users will not be able to open the file unless they have execute access through all of the enclosing directories.

See if you can cat the file as the user. If you can't then that might be the problem. If you can then you have a security problem because password hashes shouldn't be visible to normal users in trusted mode. Either way you'll know something more than you do now.

[Denver Osborn]

>The vendor's daemon is not running as root. It >is running as Zuser. Anyway, I think the trace >shows it is trying to open in read-only mode, >and the tcb file is world readable.

A non-root user wouldn't have access to /tcb/files/auth/Z/.

Have you tested running the daemon as root to verify that this isn't the problem?

-denver

[Denver Osborn]

John,

In your trace before open /etc/passwd, do you see entries for getpwnam or getspwnam?

-denver

[John Kittel]

Sorry for the delay. I got interrupted.

Right, Zuser cannot cat the tcb file.

I have not tested running the daemon as root. Let me see if I can do that.

[John Kittel]

Thanks you for the help. The problem is solved. I never got to trying to run daemon as root. DBA working with vendor determined their user setup within their application software was wrong. Something like, it encrypts the password, stores it, then when the user wants to begin some function, it decrypts that to get plain text password back, then uses plain text as input to pass to hp-ux authentication.