why would syslog report an action as "unknown" when it is clear I'm su(ing)

[Kirk Reindl]

System specs

Rp8420
HPUX 11.11
Patch level

# swlist | grep 2006
GOLDAPPS11i B.11.11.0612.459 Applications Patches for HP-UX 11i v1, December 2006
GOLDBASE11i B.11.11.0612.459 Base Patches for HP-UX 11i v1, December 2006
HWEnable11i B.11.11.0612.458 Hardware Enablement Patches for HP-UX 11i v1, December 2006
OnlineDiag B.11.11.18.05 HPUX 11.11 Support Tools Bundle, Dec 2006
root@b8mkesd6[/root]
#


Our auditors are putting the heat on me to resolve why on one server su actions are clearly logged to syslog and on another server they are not. I realize I can get su activity from the /var/adm/su log but the auditors are adamant on obtaining the su activity from syslog.

The log of the "non-working" server identifies other activity like, ftpd, ssh, but no su. To be honest I’m not sure what happens “behind the scenes” when someone authenticates to a server and exactly how the log gets updated. If I knew that, I might be able to figure out why I see the inconsistency between these two servers.

Here is the difference.

b8mkesd6 --Not working

I'll su from my regular account to root, now I have another window open running tail –f on the syslog ---Notice it doesn't even list my regular user account as logging in or the action being performed. Just the "unknown" entry

b8mkesd6:/home/techsup/creindk> whoami
creindk
b8mkesd6:/home/techsup/creindk> su -
Password: -----------I successfully key in password and get authenticated here.

HERE IS the SYSLOG
Jun 19 08:26:48 b8mkesd6 unknown[21299]: WARN pam Authentication for user 'root': User is mapped to a non-existent Active Directory account. Passing user to next service module.

b8mkesd6:/root> what /usr/bin/su
/usr/bin/su:
$Revision: @(#) su R11.11_BL2006_0308_2 PATCH_11.11 PHCO_34545

b8mkesd6:/root>

b8mkese1 --Working

I'll su from my regular account to root, now watch I'll tail –f the syslog. ----Notice it gives the action being performed and the user, me in this case, that is su(ing)

Jun 19 08:36:19 b8mkese1 su[2446]: WARN pam Authentication for user 'root': User is mapped to a non-existent Active Directory account. Passing user to next service module.
Jun 19 08:36:26 b8mkese1 su[2446]: + td creindk-root

b8mkese1:/home/techsup/creindk > whoami
creindk
b8mkese1:/home/techsup/creindk > su -
Password:

Notice the su patch on the working server (b8mkese1) is actually older.

b8mkese1:/home/techsup/creindk > what /usr/bin/su
/usr/bin/su:
$Revision: @(#) all CUP11.11_BL2002_1004_2 PATCH_11.11 PHCO_27781
Fri Oct 4 00:27:58 PDT 2002 $
b8mkese1:/home/techsup/creindk >

I’ve opened a call to HP, but it seems like there response has been slipping during this outsource transition.

[Court Campbell]

I have never personally seen this but maybe you might try sending a HUP to syslogd.

# kill -HUP `cat /var/run/syslog.pid`

Then see if the issue still persists.

[Steven E. Protter · Accepted solution]

Shalom,

I'd recommend Court's idea.

Also perhaps reboot the system if practical.

If this persists, I would see what files are missing on the system. Maybe wtmp or btmp are missing or some other critical log file is missing in action.

Check that permissions in /etc/passwd are the same on both systems since thats where the user information comes from.

ITRC has always been faster than the response center.

What is this outsource transition about? I've never heard of it.

SEP

[Kirk Reindl]

Thanks for the responses

I've re-read the config for the syslog daemon but still the same result.

Both systems in question belong to the same NIS domain.

wtmp and btmp look are in place and get updated with login and last and lastb are functioning.

Unfortunately I will not be able to reboot the machine.

[Steven E. Protter]

Shalom,

I'd schedule a reboot and prior to that do an exhaustive comparison of working to non-working machine.

check file ownership and permissions. Any small variance can be the source of this problem.

Just for grins, make sure the system clocks are close to real time. ntp is your friend here.

SEP

[Dennis Handly]

>SEP: check file ownership and permissions.

You can do a "swverify \*" on each system and then compare.

[Kirk Reindl]

All, I'm going to do the permissions test. Then if I recall I can do like a swjob or something and it will list what is too loose, but today I'm getting pulled in a different direction. I'll update as soon as I can.

[Dennis Handly]

>if I recall I can do like a swjob

That's swverify as I said.