Some details I realized I should have included to begin with: Solaris 10, x64
Sun Ray info: VERSION: 4.2_17,REV=2009.06.24.11.48 Probably some other obvious stuff I'm leaving out but my brain's cooked. On Fri, Feb 26, 2010 at 10:10:44PM -0600, Michael Jinks wrote: > Hi List. > > We have a pam module which we wrote in-house, callable either in the > "session" or the "acount" stack, which simply turns around and calls a > script specified as an argument in pam.conf. > > The module works fine for the "login" and "other" facilities, but when I > try to call it from the dtlogin-SunRay facility, something weird > happens. Logins fail, but as far as I can tell it isn't because of > anything that happens in the add-on module itself or the script it > calls; in fact as far as I can tell, the module doesn't get loaded, and > it definitely doesn't get as far as calling its script. > > Comment out that line of pam.conf, restart nscd, and everything goes back > to normal, logins are fine. > > So, is there something unusual in the way that Sun Ray uses PAM modules > which might lead to trouble where we don't see it in simpler services? > The Sun Ray stacks are pretty long and complex, so I can't rule out a > configuration error on my end, but it seems to me that what I'm trying > to do is fairly simple from a PAM perspective. > > We're using LDAP user authentication, and that works fine. So I added a > call to our module immediately after the LDAP line, like so: > > <snip> > dtlogin-SunRay account required pam_ldap.so.1 > dtlogin-SunRay account required /opt/pam_provision/pam_provision.so > exec=/etc/tasc/provision/client.sh %u > <snip> > > Like I said, this leads to woe; comment out the second line above, and > we're fine again. > > (In the course of thrashing around with this, at one point I uninstalled > Sun Ray on my test rig and reinstalled it, with calls to our module > still in pam.conf for "login" and "other"; when I did that, I noticed > that the PAM setup stage of the Sun Ray installer aped those lines for > the dtlogin-SunRay, dtsession-SunRay, utnsclogin, and uthotdesk > facilities. (Clever, though I think we exposed a bug, since that > trailing "u" in our line was repeated a couple dozen times in the added > lines; whatever, moving right along.) Reassuringly, the custom lines > also got placed just after the LDAP line, same as I'd guessed they > should go, but behavior remained the same: with the line in place for > the dtlogin-SunRay section, logins fail; take it out, they come back.) > > Our module includes a log option, e.g.: > > other account required /opt/pam_provision/pam_provision.so > log=local1 exec=/etc/tasc/provision/client.sh %u > > ...which will cause an ssh login to throw a line to a debug log: > > Feb 26 22:06:05 dumb sshd[20489]: [ID 836537 local1.info] pam_provision: > executing "/etc/tasc/provision/client.sh" "mjinks" > > ...but no such logs are forthcoming when I try to use it for Sun Ray, > which further convinces me that PAM doesn't even try to load it when we > call it for Sun Ray stuff, it just fails. > > Googling for "sun ray pam" and such hasn't turned up anything that looks > relevant so far, so here I am. Can somebody point me to the right doc > to read, or something? Happy also to provide more info -- logs or > whatever -- if I knew what might be useful. > > Thanks, > --Michael > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
