Nothing returned from passwd file.
You might have a NIS service disruption and the content would be provided by the name service cache daemon (nscd).
What says
ypwhich
?
ypwhich says:
ypwhich: can't communicate with ypbind
Also I do see a root daemon running as /usr/sbin/nscd .
Hmm, then the passwd ghost data does not come from one of the passwd sources.
Yes, the nscd is between getent and nsswitch.conf.
Maybe it is partly hung, not deleting entries from its cache?
Shut it down, Solaris 10:
svcadm disable svc:/system/name-service-cache:default
Does it help?
Since I am not an admin it says:
svcadm: svc:/system/name-service-cache:default: Permission denied.
So do you mean the result I am getting may be due to nscd's temporary cache? Is there any other way I could find out if other authentication mechanisms are being used like Siteminder etc.?
If getent finds a non-existing user, and a direct lookup in the passwd: resources (listed in /etc/nsswitch.conf) does not find the user, then I have no other idea than a corrupted nscd.
Turn to your system administrator!
So far the OS level.
On application level one can implement further user identities that are not known by the OS.
For these you must refer to the application documentation or to the application vendor/support.
Not necessarily a corrupted nscd. It might on the opposite show a properly working nscd.
There is here an obvious issue with the NIS service as NIS is enabled in nsswitch.conf but the NIS server doesn't reply to queries.
nscd might just be doing its job in providing information during its retention period. The nscd.conf manual page suggests 12 hours for NIS but it can certainly set for more.
I believe there might be some other Access Control software like Quest Privilege Manager or Cisco SA Control etc. That could be a reason why we are seeing this behavior?
---------- Post updated at 10:07 AM ---------- Previous update was at 09:59 AM ----------
I am seeing same parameters for various attributes in nscd.conf:
positive-time-to-live audit_user 3600
negative-time-to-live audit_user 5
keep-hot-count audit_user 20
check-files audit_user yes
Any third party product that interfere with the regular naming service could indeed be the culprit.
I am checking on that, thanks.
At last I was able to get some information. It looks like there is an Access control mechanism in place which apparently the sysadmins didn't share information much and that seems to be the issue as confirmed. Thanks for both of you who helped to trace this issue out :).
Thank you for letting us know what the underlying problem was.