Damon Getsman schrieb:
Well first of all I'd very much like to thank you for that detailed
explanation of the pam modules. It's helping me to understand much
better what is going on in those pam scripts, especially /etc/pam.d/gdm,
which is where I believe the issue is most probably taking place.
I did run across a module that you didn't mention, however.
<sunlib>/pam_kiosk.so, and I've been unable to find any more detailed
information than the manpage for it (in /opt/SUNWKio...). The manpage
is still leaving me a little confused, as it appears that this module
has many different possible behaviors.
The core sentence for your case is:
1. [all modules] Return PAM_IGNORE and perform no further
action, if the session is known not to be a Kiosk ses-
sion.
That means that unless you have configured some/all X sessions to be
kiosk sessions (using the kioskconfig(8) tool or the SRSS functionality
built on top of it) this module, will do nothing and return PAM_IGNORE.
What is unclear about this description?
For most intents and purposes this means that, if you know that you'll
never need kiosk mode, you could remove these entries from the pam.d/gdm
file without doing any harm. OTOH this should not change anything for
your PAM processing and SRSS may restore the entires it has made
(including the pam_kiosk ones) under certain circumstances.
Honestly I'm not even sure what
kiosk mode would be used for in our setting, as every user has to
authenticate at the gdm screen and we have no unauthenticated sessions.
This is probably due to the fact that I don't have much understanding of
the module, however.
Typical uses include running a full screen Sun Ray Windows Connector
session or running another full-screen frontend to some network-based
service (e.g. in a stripped down web browser) without requiring a Unix
login.
This is the context in which it appears:
-=-=-
#%PAM-1.0
password include common-password
# BEGIN: added to gdm by SunRay Server Software -- gdm
auth requisite /opt/SUNWut/lib/sunray_get_user.so.1 property=username
auth required /opt/SUNWut/lib/pam_sunray_amgh.so.1
auth sufficient /opt/SUNWkio/lib/pam_kiosk.so log=user ignoreuser
auth requisite /opt/SUNWkio/lib/pam_kiosk.so log=user
auth required /opt/SUNWut/lib/sunray_get_user.so.1 prompt
auth required /opt/SUNWut/lib/pam_sunray_amgh.so.1 clearuser
auth include common-auth
session required /opt/SUNWkio/lib/pam_kiosk.so log=user
session required pam_loginuid.so
session include common-session
session required pam_resmgr.so
account sufficient /opt/SUNWkio/lib/pam_kiosk.so log=user
account include common-account
-=-=-
This looks all sane. Unless you actually use any of the relevant SRSS
functionality (AMGH or Kiosk Mode) you could remove all of the
SRSS-generated PAM entries (all the entries that point to /opt/SUNW*)
without doing harm. But in that case these modules should all be
passive, so I would be surprise, if that improved your situation.
Is there any chance that you could explain to me the behavior of that
particular module a bit?
See above. The behavior if a session is configured for Kiosk Mode is
described in the man page in quite some detail. What is lacking there?
Also, thanks to the greater pouring over documentation that I did today
compared to previously, I figured out where I think the PAM modules are
dumping their logging information on these systems. The only
authentication error I saw from my testing the other day was the following:
-=-=-
/var/log/warn:May 26 13:22:15 srss-bismarck-gamma gdm[4175]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:22:28 srss-bismarck-gamma gdm[4175]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:29:16 srss-bismarck-gamma gdm[13323]:
pam_krb5[13323]: error resolving user name 'dgetsman' to uid/gid pair
/var/log/warn:May 26 13:29:19 srss-bismarck-gamma gdm[13323]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:36:45 srss-bismarck-gamma gdm[6638]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:37:17 srss-bismarck-gamma gdm[6846]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:41:12 srss-bismarck-gamma gdm[6846]: WARNING:
Couldn't authenticate user
/var/log/warn:May 26 13:42:33 srss-bismarck-gamma gdm[6846]: WARNING:
Couldn't authenticate user
These warnings are rather unspecific. It is hard to tell where things go
wrong. It might be useful, if you have a syslog target which captures
more messages (at notice, info or even debug level). It may also be
helpful if you add 'debug' options to some of modules in
/etc/pam.d/common-auth, which is where the real authentiaction behavior
is defined.
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8323]: fatal:
login_init_entry: Cannot find user "dgetsman"
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8323]: fatal:
login_init_entry: Cannot find user "dgetsman"
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8328]:
pam_krb5[8328]: error resolving user name 'dgetsman' to uid/gid pair
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8328]:
pam_krb5[8328]: no user info for dgetsman (shouldn't happen)
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8328]:
pam_krb5[8328]: error resolving user name 'dgetsman' to uid/gid pair
/var/log/warn:May 26 13:52:21 srss-bismarck-gamma sshd[8328]:
pam_krb5[8328]: no user info for dgetsman (shouldn't happen)
-=-=-
If 'dgetsman' is supposed to be a valid login name, then your name
service configuration (/etc/nsswitch.conf) is probably wrong.
You said before that LDAP login works for ssh or console login. Is that
really using the same login name and password which fails under gdm?
Now I can't be sure as I'm still learning about the SRSS PAM modules and
admittedly still have a LONG way to go, but I'd imagine that if the
problem encompassed more than just kerberos, I'd see other modules
complaining in the log.
Yes. If you wish you can try removing all SRSS modukes from the gdm
file. If the failures still occur, you know for sure that the problem is
a in one of the modules listed in the common-{auth,account,session} files.
HTH
- Jörg
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
