My first choice is to do it using pam_groupdn, because then it's only one file that gets altered (/etc/ldap.conf). I don't really see a reason for it not to work, unless an RPM was goofed up or my config is wrong, which is hard to do being that it's ONE key/value pair.
My second option is to use 'compat' mode and reference a netgroup (stored in LDAP) in my passwd/shadow files. This doesn't seem to be as straightforward as I thought it might be. I can see the searches going by for the netgroup, but the filter isn't being 'OR'd with a uid of any kind.
Your idea is already on the list of stuff that I *can* do if I'm cornered, but this workaround doesn't address why the initial problem occurs. Option one was easy in RH 9, option 2 works in RH ES/AS/WS, option 3 will probably work, but this is horribly inconsistent and gives the appearance of flakiness. I was hoping not to have to tear open source rpms and code, but...
Thanks again, brian.
Bevan C. Bennett wrote:
Brian Jones wrote:
Hi,
Just looking for confirmation: Anyone using fedora core 1 with 'pam_groupdn' enabled in the ldap.conf file? I've used this before on RH 9 without a problem, but now I'm not even seeing any searches going to my LDAP server at all with regard to the value in pam_groupdn. It's as if the value is being completely ignored. No errors either.
No help with pam_groupdn, but if what you're trying to accomplish is, for example, to only allow administrative ssh access to a server, you might want to try something like the following instead:
Add the following line into /etc/pam.d/sshd account required pam_access.so
(also into telnetd and any other services you want to restrict)
Add the following list to /etc/security/access.conf -:ALL EXCEPT wheel itgroup:ALL
Where 'itgroup' is a POSIX group containing your allowed users, possibly stored in LDAP.
I dimly recall playing with pam_groupdn for awhile then abandoning those efforts in favor of this approach.
