Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Well a big thing you (apparently) would benefit from appreciating is the abstraction involved. When you log in, the source of the user account is totally irrelevant. You would not filter against an LDAP group at all, just a group, as listed by the response to the command "getent group" - divide and conquer!
MY preferred way to do this is to add that group requirement to /etc/security/access.conf, but other users would suggest you use the "AllowGroups" directive in /etc/ssh/sshd_config
As far as the LDAP stuff really goes, as long as you do have full posix accounts within LDAP, which you should, then there's really not much else to require, what have you been reading that suggests otherwise?
well naturally you need to get the full login stuff sorted before you can filter. what does "getent group dev" say? Is dev not a system group? Also you would use @dev to signify a group, as without it it just suggests a user. Having said *that* though, that still suggests that access.conf isn't being read right possibly.
I just get the one line output, showing the contents of the LDAP server. dev isn't a local group. Adding @dev makes no difference in the access.conf file.
The sshd AllowGroups option does in fact work, but it doesn't report to the user that they can't login, it just appears that their password doesn't work. If that's the only option then I'll use it but I'd prefer they be told "login not allowed"!
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
Not come across pam access not being there by default. Checking some examples in the access.conf manpage did still ist @ notation.
As far as informing the user, I think that *IF* it matters there are ways to send data back to the user with some of the less common branching and logic modules that some people have written for PAM. Fundamentally though, security is about not disclosing unnecessary information, so not common to want to deliberately give more information back.