I asked on here for help with setting up PAM authentication through LDAP before and received help which assisted me in getting several OpenSuSE 10.3 servers authenticating all services through my OpenLDAP directory (on a separate Ubuntu 7.10 server VM). Unfortunately I'm having some issues again that are holding me back a bit.
My LDAP authentication migration was put on hold because of a few other projects that came my way with higher priority. Due to issues with rebooting when nsswitch.conf was looking for ldap I disabled all LDAP authentication and left it at compat for the interim. Then a week ago I got a chance to unroll the project again, but my main testing server had died. So I put the drive in another machine and got my ldap.conf, nsswitch.conf, and the entirety of my pam.d directory and put it onto another identical server (they're made from tarballs of each other, except for this one set of files on the testing box). When I swapped it out, at first nscd messed with me for a bit, then I remembered to kill it and POOF. LDAP authentication over login and sshd worked just fine; both of those rulesets using the common-auth, common-account, and common-session files that have the following contents taken from http://www.howtoforge.com/linux_ldap_authentication. Before I paste the rules, I have been told that they're 'broken', but they worked perfectly for me before and work at almost all of the services for me now... -=-=-=- auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_ldap.so password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok password sufficient pam_ldap.so use_first_pass password required pam_deny.so session required pam_limits.so session required pam_unix.so session optional pam_ldap.so -=-=-=- So anyway for about 5 days or so now I've been pulling my stubble out trying to figure out why the gdm sessions aren't authenticating for my users when the other methods that the admins use are working just fine... The more I looked the less it made sense. Finally, being as there are several /etc/pam.d/gdm* rulesets, I began to try singling them out to determine what was causing the issue... a chmod 000 of /etc/pam.d/gdm* left gdm still able to authenticate but only over files; so it's got to be using something else... Another weird thing... If I logged in to a gdm session via one of our terminals, and then wipe my own /etc/passwd and /etc/shadow entries (with ldap as the backup form of authentication), xlock will let me authenticate via ldap without any problems as well. The problem appears to JUST be gdm, although I haven't been able to actually try a console login because the server is headless in a rack. Here is a copy of the rules for gdm, also, although I'm fairly certain (with my limited knowledge) that they don't apply: -=-=-=- #%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 -=-=-=- I was a little hesitant to post those because I know that most people are wondering what all of the /opt/SUNWut/* stuff is. The last time I got everything authenticating I spoke to the developers for the Sun terminals that we use to connect to the server machines; these are just services that set things up for the terminal-- NONE of them fail regardless of what happens, so they are not affecting the PAM stack. ALL authentication is still performed through the common-* includes. I would really appreciate any pointers to PAM specific groups/forums/mailing lists that anybody could give, or any help for this actual situation. I'm sure that more information is applicable but I'm not quite sure what to paste in here; if there's anything else you'd like to see please let me know and I'll be happy to provide. Missing this one service authenticating over PAM/LDAP is completely shooting down the main reason for adding this service, which is to centralize the BULK of our users, not just our admins. Thank you so much in advance. -Damon Getsman http://www.mail-archive.com/[EMAIL PROTECTED]/msg09781.html has more information on the configuration for SunRay terminals and their associated PAM modules that I'm working with. Actually it was a message from Bob Doolittle that had more on the Sun modules themselves, but this guy repeats it fairly definitively. :) P.S. You can see what a complete novice I was at LDAP when I was writing these messages; I assure you I know a little bit more now, at least. :) --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
