You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, the most common way I see people implementing YubiKey in a manner that allows them to specify which users should require a key is via a little extended syntax in PAM. Not doing so essentially forces all users to need a YubiKey. That syntax, for those interested in the quick fix (Linux PAM ONLY) is as follows:
That success=1 will tell PAM to skip the next X lines (in this case, 1) if the user is not in the specified group. However, if you're NetBSD'ish or on Mac OS X, you're using OpenPAM which does not support this extended syntax.
My solution was originally going to be to simply look in the users home directory for a .yubico directory, and just return PAM_SUCCESS and skip over everything if it didn't exist. However, it seems the most common method of assigning which accounts should use the key thus far has been to create a group and add users to it. So, I figured, why not stick to that methodology?
I'm going to use getgrouplist() to identify whether or not the user is in the group. This should work across Linux and BSD alike.
This will certainly meet the needs for my implementation... The question is, will anyone else be interested in such an addition? If so, I'll setup a pull request once I get it done (some time tonight or early tomorrow morning). If a pull request isn't desired or you aren't interested in it as being part of the module, I will simply put the modifications here in a comment for anyone else that may be interested.
The text was updated successfully, but these errors were encountered:
I've submitted a pull request to merge the changes. In my fork, there's now the ability to specify a PAM module parameter: authgroup= . If used, only users in the specified group would have to use a yubikey to authenticate in challenge-response mode. i.e.:
authgroup=yubikey would only attempt challenge-response authentication on users that are in the yubikey group. This resolves the issue of not being able to put challenge-response authentication on specific users, and not all of them.
I apologize for the indentation changes, my editor does that automatically, and I just noticed it.
The changes were made in the cfg struct (addition of const char *authgroup), util.c (addition of CheckGroup function), util.h (included string.h, grp.h and pwd.h) and yubico_pam.c (do_challenge_response function at the near-beginning and also in the config parse function with the addition to check for authgroup= ).
As it stands, the most common way I see people implementing YubiKey in a manner that allows them to specify which users should require a key is via a little extended syntax in PAM. Not doing so essentially forces all users to need a YubiKey. That syntax, for those interested in the quick fix (Linux PAM ONLY) is as follows:
auth [success=1 default=ignore] pam_succeed_if.so quiet user notingroup [groupname]
auth required pam_yubico.so mode=challenge-response
That success=1 will tell PAM to skip the next X lines (in this case, 1) if the user is not in the specified group. However, if you're NetBSD'ish or on Mac OS X, you're using OpenPAM which does not support this extended syntax.
My solution was originally going to be to simply look in the users home directory for a .yubico directory, and just return PAM_SUCCESS and skip over everything if it didn't exist. However, it seems the most common method of assigning which accounts should use the key thus far has been to create a group and add users to it. So, I figured, why not stick to that methodology?
I'm going to use getgrouplist() to identify whether or not the user is in the group. This should work across Linux and BSD alike.
This will certainly meet the needs for my implementation... The question is, will anyone else be interested in such an addition? If so, I'll setup a pull request once I get it done (some time tonight or early tomorrow morning). If a pull request isn't desired or you aren't interested in it as being part of the module, I will simply put the modifications here in a comment for anyone else that may be interested.
The text was updated successfully, but these errors were encountered: