Re: ldap.conf: 'pam_groupdn' being completely ignored?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again.

Bevan C. Bennett wrote:

IIRC, pam_groupdn will restrict access for all services that reference pam_ldap.

This is precisely the functionality I'm looking to implement. For some machines, only a small number of people should have any access whatsoever, using any service.



If I understand correctly, you haven't changed the LDAP server any, and

the LDAP server hasn't changed in months.

this works on a RH9 box with the same ldap.conf file? Do the pam_ldap entries differ substantially between the two boxes in the relevant /etc/pam.d/* files (probably system-auth)?

Actually, this isn't exactly true, only because the machine I'm working with now *was* the RH9 box that used to work - I upgraded it to FC1. I can't verify that the files are precisely the same.



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.


That sounds nasty and kludgy.

I suppose, but I think I'd sooner think to look in nsswitch.conf for a problem than /etc/security/access.conf. In the end, it's not really nasty and kludgy if your systems are already set up that way, and the kickstart templates are already fixed this way as well ;-)



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...


Very true, but it's always good to have options. Why do you say that using pam_access gives the appearance of flakiness? I've found it to be robust on servers running RH7.3 through FC1.

I'm sorry - I didn't make myself clear there. What makes things appear flaky is the fact that things that really should 'just work'(tm), like the pam_groupdn stuff (which I had working in RH 9), don't. Compat mode, which 'just works' under redhat ES/WS/AS, also fails here in FC 1.



Let's see if we can narrow down your pam_groupdn problems better. Discussing whether or not pam_groupdn is the best solution to your particular environment is a rather different (although potentially interesting) discussion that we can leave for later.

True.

Unfortunately, I have really no clue where to start in narrowing this one down. There are NO messages from the LDAP server that indicate that the client is even *trying* to verify group membership. On the client side of things, strace hasn't been much help yet. I'll post some more verbose ldap logs tomorrow, but as of now, they've been little help either. Seems there's no trace of the values in pam_groupdn. More tomorrow.

Thanks,
brian.

-Bevan Bennett






[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux