Using pam_succeed_if to restrict user login to single group

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite
1












I'm running Debian 9. I'm no PAM expert. What I want to do is restrict user logins to uids that are members of the "goodgroup" group. I forget where I got this solution originally, but this is what I have in my /etc/pam.d/common-account:



.
.
.
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
account sufficient pam_localuser.so

# >>> This is where I'm trying to do it <<<
account requisite pam_succeed_if.so user ingroup goodgroup

account [default=bad success=ok user_unknown=ignore] pam_sss.so
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore auth
info_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config


Let's say I have a uid "baduid" that's not in the required group. What I'd like to happen is that trying "su baduid" as root should fail completely. What actually happens is that the su is successful but baduid has no associated home directory.



Here's what I see in the log file when I do "su baduid":



May 3 16:08:03 myhost su[3014]: pam_succeed_if(su:account): requirement "user ingroup goodgroup" not met by user "baduid"
May 3 16:08:03 myhost su[3014]: Successful su for baduid by root
May 3 16:08:03 myhost su[3014]: + /dev/pts/0 root:baduid
May 3 16:08:03 myhost su[3014]: pam_unix(su:session): session opened for user baduid by root(uid=0)
May 3 16:08:03 myhost su[3014]: pam_systemd(su:session): Cannot create session: Already running in a session


Any help in trying to achieve my goal would be greatly appreciated.



Matthew Wyneken







share|improve this question















  • 1




    Have you tried using the auth version instead of account?
    – Chiraag
    May 3 at 16:34










  • Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
    – Matthew Wyneken
    May 8 at 14:15










  • It's a bit late, but maybe using pam_access as here is more successful?
    – Tobias
    Jul 20 at 7:56














up vote
1
down vote

favorite
1












I'm running Debian 9. I'm no PAM expert. What I want to do is restrict user logins to uids that are members of the "goodgroup" group. I forget where I got this solution originally, but this is what I have in my /etc/pam.d/common-account:



.
.
.
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
account sufficient pam_localuser.so

# >>> This is where I'm trying to do it <<<
account requisite pam_succeed_if.so user ingroup goodgroup

account [default=bad success=ok user_unknown=ignore] pam_sss.so
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore auth
info_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config


Let's say I have a uid "baduid" that's not in the required group. What I'd like to happen is that trying "su baduid" as root should fail completely. What actually happens is that the su is successful but baduid has no associated home directory.



Here's what I see in the log file when I do "su baduid":



May 3 16:08:03 myhost su[3014]: pam_succeed_if(su:account): requirement "user ingroup goodgroup" not met by user "baduid"
May 3 16:08:03 myhost su[3014]: Successful su for baduid by root
May 3 16:08:03 myhost su[3014]: + /dev/pts/0 root:baduid
May 3 16:08:03 myhost su[3014]: pam_unix(su:session): session opened for user baduid by root(uid=0)
May 3 16:08:03 myhost su[3014]: pam_systemd(su:session): Cannot create session: Already running in a session


Any help in trying to achieve my goal would be greatly appreciated.



Matthew Wyneken







share|improve this question















  • 1




    Have you tried using the auth version instead of account?
    – Chiraag
    May 3 at 16:34










  • Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
    – Matthew Wyneken
    May 8 at 14:15










  • It's a bit late, but maybe using pam_access as here is more successful?
    – Tobias
    Jul 20 at 7:56












up vote
1
down vote

favorite
1









up vote
1
down vote

favorite
1






1





I'm running Debian 9. I'm no PAM expert. What I want to do is restrict user logins to uids that are members of the "goodgroup" group. I forget where I got this solution originally, but this is what I have in my /etc/pam.d/common-account:



.
.
.
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
account sufficient pam_localuser.so

# >>> This is where I'm trying to do it <<<
account requisite pam_succeed_if.so user ingroup goodgroup

account [default=bad success=ok user_unknown=ignore] pam_sss.so
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore auth
info_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config


Let's say I have a uid "baduid" that's not in the required group. What I'd like to happen is that trying "su baduid" as root should fail completely. What actually happens is that the su is successful but baduid has no associated home directory.



Here's what I see in the log file when I do "su baduid":



May 3 16:08:03 myhost su[3014]: pam_succeed_if(su:account): requirement "user ingroup goodgroup" not met by user "baduid"
May 3 16:08:03 myhost su[3014]: Successful su for baduid by root
May 3 16:08:03 myhost su[3014]: + /dev/pts/0 root:baduid
May 3 16:08:03 myhost su[3014]: pam_unix(su:session): session opened for user baduid by root(uid=0)
May 3 16:08:03 myhost su[3014]: pam_systemd(su:session): Cannot create session: Already running in a session


Any help in trying to achieve my goal would be greatly appreciated.



Matthew Wyneken







share|improve this question











I'm running Debian 9. I'm no PAM expert. What I want to do is restrict user logins to uids that are members of the "goodgroup" group. I forget where I got this solution originally, but this is what I have in my /etc/pam.d/common-account:



.
.
.
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
account sufficient pam_localuser.so

# >>> This is where I'm trying to do it <<<
account requisite pam_succeed_if.so user ingroup goodgroup

account [default=bad success=ok user_unknown=ignore] pam_sss.so
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore auth
info_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config


Let's say I have a uid "baduid" that's not in the required group. What I'd like to happen is that trying "su baduid" as root should fail completely. What actually happens is that the su is successful but baduid has no associated home directory.



Here's what I see in the log file when I do "su baduid":



May 3 16:08:03 myhost su[3014]: pam_succeed_if(su:account): requirement "user ingroup goodgroup" not met by user "baduid"
May 3 16:08:03 myhost su[3014]: Successful su for baduid by root
May 3 16:08:03 myhost su[3014]: + /dev/pts/0 root:baduid
May 3 16:08:03 myhost su[3014]: pam_unix(su:session): session opened for user baduid by root(uid=0)
May 3 16:08:03 myhost su[3014]: pam_systemd(su:session): Cannot create session: Already running in a session


Any help in trying to achieve my goal would be greatly appreciated.



Matthew Wyneken









share|improve this question










share|improve this question




share|improve this question









asked May 3 at 14:26









Matthew Wyneken

62




62







  • 1




    Have you tried using the auth version instead of account?
    – Chiraag
    May 3 at 16:34










  • Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
    – Matthew Wyneken
    May 8 at 14:15










  • It's a bit late, but maybe using pam_access as here is more successful?
    – Tobias
    Jul 20 at 7:56












  • 1




    Have you tried using the auth version instead of account?
    – Chiraag
    May 3 at 16:34










  • Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
    – Matthew Wyneken
    May 8 at 14:15










  • It's a bit late, but maybe using pam_access as here is more successful?
    – Tobias
    Jul 20 at 7:56







1




1




Have you tried using the auth version instead of account?
– Chiraag
May 3 at 16:34




Have you tried using the auth version instead of account?
– Chiraag
May 3 at 16:34












Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
– Matthew Wyneken
May 8 at 14:15




Thanks for responding, and sorry for taking to long to answer. I tried putting the line in the auth file, making appropriate alterations. It didn't do any good.
– Matthew Wyneken
May 8 at 14:15












It's a bit late, but maybe using pam_access as here is more successful?
– Tobias
Jul 20 at 7:56




It's a bit late, but maybe using pam_access as here is more successful?
– Tobias
Jul 20 at 7:56















active

oldest

votes











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f441565%2fusing-pam-succeed-if-to-restrict-user-login-to-single-group%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes










 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f441565%2fusing-pam-succeed-if-to-restrict-user-login-to-single-group%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay