Lanthier schrieb:
Dear lists members,
I have a solaris 10 box acting as a Sun Ray server, v4.0.
I used likewise-open software to enable authentication against an
Active Directory 2003 server on this solaris box.
I was then able to login on my solaris box by ssh or directly on the
graphical console, both with local accounts and the AD2003 accounts.
But, on the Sun Ray Client, I was able to login only with local
accounts (ie. the ones in /etc/passwd).
I took a look on the error messages I got when I joined the AD2003
domain. Then, I added some lines in my /etc/pam.conf, some
"dtlogin-SunRay auth" and "xsreensaver auth" lines
I'm writing all this because :
1) It could inspire people that have problems to connect to Sun Rays with non
local users
2) I would like a "pam expert" to verify and confirm the order of my
new lines. The new lines are the ones directly below the "Ajout par
Stephanie" lines.
It is hard to tell where the new entries need to go without seeing the
spec/man-page etc. That said, the 'other' stack is what is used for
graphical login (as you have no separate 'dtlogin' stack and the 'login'
one is used for text login. So these are good examples to go by.
Speculating about the meaning of the various parameters of the
pam_lwidentity module, I would guess that in your configuration a few
things (kiosk, NSCM) may not work as intended.
The logic used by Sun Ray setup is to place all Sun Ray specific entries
(sunray_get_user.so, pam_sunray_amgh.so, pam_kiosk.so, pam_sunray.so) at
the top of the PAM stack *before* the usual dtlogin/other stack. From my
wild guess at the functions of the pam_lwidentity module, this appears
to be the best approach here as well.
That would mean that you should have the following pam.conf entries for
the relevant stacks:
This one is the 'template' the proposed stacks are built from:
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_lwidentity.so
set_default_repository
other auth requisite pam_authtok_get.so.1
other auth sufficient pam_lwidentity.so try_first_pass
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_lwidentity.so unknown_ok
other account sufficient pam_lwidentity.so
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
other session sufficient pam_lwidentity.so
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password sufficient pam_lwidentity.so try_first_pass
use_authtok
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
In the dtlogin-SunRay stack I suggest to omit the password one, because
here the 'other' one should do.
Otherwise the Sun Ray entries should come first as explained above:
# BEGIN: added to dtlogin-SunRay by SunRay Server Software -- dtlogin-SunRay
dtlogin-SunRay auth requisite /opt/SUNWut/lib/sunray_get_user.so.1
property=username
dtlogin-SunRay auth required /opt/SUNWut/lib/pam_sunray_amgh.so.1
dtlogin-SunRay auth sufficient /opt/SUNWkio/lib/pam_kiosk.so log=user ignoreuser
dtlogin-SunRay auth requisite /opt/SUNWkio/lib/pam_kiosk.so log=user
dtlogin-SunRay auth sufficient /opt/SUNWut/lib/pam_sunray.so
dtlogin-SunRay auth requisite /opt/SUNWut/lib/sunray_get_user.so.1 prompt
dtlogin-SunRay auth required /opt/SUNWut/lib/pam_sunray_amgh.so.1 clearuser
dtlogin-SunRay auth requisite pam_lwidentity.so set_default_repository
dtlogin-SunRay auth requisite pam_authtok_get.so.1
dtlogin-SunRay auth sufficient pam_lwidentity.so try_first_pass
dtlogin-SunRay auth required pam_dhkeys.so.1
dtlogin-SunRay auth required pam_unix_cred.so.1
dtlogin-SunRay auth required pam_unix_auth.so.1
The same applies to the account and session stacks:
dtlogin-SunRay account sufficient /opt/SUNWkio/lib/pam_kiosk.so log=user
dtlogin-SunRay account sufficient /opt/SUNWut/lib/pam_sunray.so
dtlogin-SunRay account requisite pam_roles.so.1
dtlogin-SunRay account required pam_lwidentity.so unknown_ok
dtlogin-SunRay account sufficient pam_lwidentity.so
dtlogin-SunRay account required pam_unix_account.so.1
dtlogin-SunRay session required /opt/SUNWkio/lib/pam_kiosk.so log=user
dtlogin-SunRay session required pam_unix_session.so.1
dtlogin-SunRay session sufficient pam_lwidentity.so
I'm not sure about the correct xscreensaver stack, but would again suggest:
# BEGIN: added to xscreensaver by SunRay Server Software -- xscreensaver
xscreensaver auth sufficient /opt/SUNWut/lib/pam_sunray.so syncondisplay
xscreensaver auth sufficient pam_lwidentity.so set_default_repository
xscreensaver auth requisite pam_authtok_get.so.1
xscreensaver auth sufficient pam_lwidentity.so try_first_pass
xscreensaver auth required pam_dhkeys.so.1
xscreensaver auth required pam_unix_cred.so.1
xscreensaver auth required pam_unix_auth.so.1
And similarly for the dtsession-SunRay stack (which is also for a screen
lock):
# BEGIN: added to dtsession-SunRay by SunRay Server Software -- dtsession-SunRay
dtsession-SunRay auth sufficient /opt/SUNWut/lib/pam_sunray.so syncondisplay
dtsession-SunRay auth requisite pam_authtok_get.so.1
dtsession-SunRay auth required pam_dhkeys.so.1
dtsession-SunRay auth required pam_unix_cred.so.1
dtsession-SunRay auth required pam_unix_auth.so.1
You seem to have the utnsclogin stack right, but again it may be best to
omit the stacks that don't deviate from the 'other' stack.
# BEGIN: added to utnsclogin by SunRay Server Software -- utnsclogin
utnsclogin auth requisite /opt/SUNWut/lib/sunray_get_user.so.1 property=username
utnsclogin auth required /opt/SUNWut/lib/pam_sunray_amgh.so.1
utnsclogin auth requisite pam_lwidentity.so set_default_repository
utnsclogin auth requisite pam_authtok_get.so.1
utnsclogin auth sufficient pam_lwidentity.so try_first_pass
utnsclogin auth required pam_dhkeys.so.1
utnsclogin auth required pam_unix_cred.so.1
utnsclogin auth required pam_unix_auth.so.1
To be clear: this is little more than an educated guess. The most
non-obvious part is the placement of the
dtlogin-SunRay auth requisite pam_lwidentity.so set_default_repository
line in the 'auth' stack. If that line is required to be run for the
subsequent modules (account, session) to work properly, then it may need
to be moved to the top of the stack, as you did in the pam.conf you
included. But if it needs a username, then it must not be placed before
pam_sunray.so and pam_kiosk.so - in the worst case here could be a real
incompatibility with NSCM.
Let us know how it works for you. We are interested in knowing how well
SRSS works with such third-party authentication mechanisms.
Regards
- Jörg
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
