Password history restrictions are written to in system-auth(-ac), but not password-auth(-ac). Why, when every other policy gets written to both?
Clash Royale CLAN TAG#URR8PPP
According to this STIG, password history is entered into /etc/pam.d/system-auth, but not /etc/pam.d/password-auth. Other policies, for example, account lockouts are applied to both files.
Why isn't the password history entered into both, or is this just a typo in the STIG? (Hard to believe that second, but it happens.)
linux security pam
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
add a comment |
According to this STIG, password history is entered into /etc/pam.d/system-auth, but not /etc/pam.d/password-auth. Other policies, for example, account lockouts are applied to both files.
Why isn't the password history entered into both, or is this just a typo in the STIG? (Hard to believe that second, but it happens.)
linux security pam
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
add a comment |
According to this STIG, password history is entered into /etc/pam.d/system-auth, but not /etc/pam.d/password-auth. Other policies, for example, account lockouts are applied to both files.
Why isn't the password history entered into both, or is this just a typo in the STIG? (Hard to believe that second, but it happens.)
linux security pam
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
According to this STIG, password history is entered into /etc/pam.d/system-auth, but not /etc/pam.d/password-auth. Other policies, for example, account lockouts are applied to both files.
Why isn't the password history entered into both, or is this just a typo in the STIG? (Hard to believe that second, but it happens.)
linux security pam
linux security pam
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
edited Dec 15 at 19:31
Jeff Schaller
38.5k1053125
38.5k1053125
asked Dec 14 at 22:07
UtahJarhead
1234
asked Dec 14 at 22:07
UtahJarhead
1234
asked Dec 14 at 22:07
UtahJarhead
1234
1234
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The password-auth and system-auth files are not directly used by any process or service. Instead, they are pulled into other PAM configuration files using the include directive. The only thing that really cares about password history on a default installation is the passwd command. It has its own PAM module, and it only pulls in system-auth:
[root@rhel7 ~]# grep include /etc/pam.d/passwd
auth include system-auth
account include system-auth
Account lockouts are recommended for both because services like sshd pull in password-auth instead. On the RHEL 7 system I'm looking at right now, system-auth is mostly pulled into PAM files for things the user would interact with directly (login, password changes, su and sudo, etc.), while password-auth is pulled in by running daemons like sshd and crond.
You can add the password history setting to pam_unix.so in password-auth for consistency, if you want to. It won't harm anything, but neither will it do anything useful.
answered Dec 14 at 22:32
James Sneeringer
1,738911
I see what you're saying. Sosshd/cronddon't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?
– UtahJarhead
Dec 14 at 22:42
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of thepasswdcommand. It's not limited to just the shell, though, since you could callpasswdfrom a script through non-interactive automation if you wanted to.
– James Sneeringer
Dec 14 at 23:04
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f488069%2fpassword-history-restrictions-are-written-to-in-system-auth-ac-but-not-passwo%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The password-auth and system-auth files are not directly used by any process or service. Instead, they are pulled into other PAM configuration files using the include directive. The only thing that really cares about password history on a default installation is the passwd command. It has its own PAM module, and it only pulls in system-auth:
[root@rhel7 ~]# grep include /etc/pam.d/passwd
auth include system-auth
account include system-auth
Account lockouts are recommended for both because services like sshd pull in password-auth instead. On the RHEL 7 system I'm looking at right now, system-auth is mostly pulled into PAM files for things the user would interact with directly (login, password changes, su and sudo, etc.), while password-auth is pulled in by running daemons like sshd and crond.
You can add the password history setting to pam_unix.so in password-auth for consistency, if you want to. It won't harm anything, but neither will it do anything useful.
answered Dec 14 at 22:32
James Sneeringer
1,738911
I see what you're saying. Sosshd/cronddon't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?
– UtahJarhead
Dec 14 at 22:42
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of thepasswdcommand. It's not limited to just the shell, though, since you could callpasswdfrom a script through non-interactive automation if you wanted to.
– James Sneeringer
Dec 14 at 23:04
add a comment |
The password-auth and system-auth files are not directly used by any process or service. Instead, they are pulled into other PAM configuration files using the include directive. The only thing that really cares about password history on a default installation is the passwd command. It has its own PAM module, and it only pulls in system-auth:
[root@rhel7 ~]# grep include /etc/pam.d/passwd
auth include system-auth
account include system-auth
Account lockouts are recommended for both because services like sshd pull in password-auth instead. On the RHEL 7 system I'm looking at right now, system-auth is mostly pulled into PAM files for things the user would interact with directly (login, password changes, su and sudo, etc.), while password-auth is pulled in by running daemons like sshd and crond.
You can add the password history setting to pam_unix.so in password-auth for consistency, if you want to. It won't harm anything, but neither will it do anything useful.
answered Dec 14 at 22:32
James Sneeringer
1,738911
I see what you're saying. Sosshd/cronddon't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?
– UtahJarhead
Dec 14 at 22:42
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of thepasswdcommand. It's not limited to just the shell, though, since you could callpasswdfrom a script through non-interactive automation if you wanted to.
– James Sneeringer
Dec 14 at 23:04
add a comment |
The password-auth and system-auth files are not directly used by any process or service. Instead, they are pulled into other PAM configuration files using the include directive. The only thing that really cares about password history on a default installation is the passwd command. It has its own PAM module, and it only pulls in system-auth:
[root@rhel7 ~]# grep include /etc/pam.d/passwd
auth include system-auth
account include system-auth
Account lockouts are recommended for both because services like sshd pull in password-auth instead. On the RHEL 7 system I'm looking at right now, system-auth is mostly pulled into PAM files for things the user would interact with directly (login, password changes, su and sudo, etc.), while password-auth is pulled in by running daemons like sshd and crond.
You can add the password history setting to pam_unix.so in password-auth for consistency, if you want to. It won't harm anything, but neither will it do anything useful.
answered Dec 14 at 22:32
James Sneeringer
1,738911
The password-auth and system-auth files are not directly used by any process or service. Instead, they are pulled into other PAM configuration files using the include directive. The only thing that really cares about password history on a default installation is the passwd command. It has its own PAM module, and it only pulls in system-auth:
[root@rhel7 ~]# grep include /etc/pam.d/passwd
auth include system-auth
account include system-auth
Account lockouts are recommended for both because services like sshd pull in password-auth instead. On the RHEL 7 system I'm looking at right now, system-auth is mostly pulled into PAM files for things the user would interact with directly (login, password changes, su and sudo, etc.), while password-auth is pulled in by running daemons like sshd and crond.
You can add the password history setting to pam_unix.so in password-auth for consistency, if you want to. It won't harm anything, but neither will it do anything useful.
answered Dec 14 at 22:32
James Sneeringer
1,738911
answered Dec 14 at 22:32
James Sneeringer
1,738911
answered Dec 14 at 22:32
James Sneeringer
1,738911
answered Dec 14 at 22:32
James Sneeringer
1,738911
1,738911
I see what you're saying. Sosshd/cronddon't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?
– UtahJarhead
Dec 14 at 22:42
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of thepasswdcommand. It's not limited to just the shell, though, since you could callpasswdfrom a script through non-interactive automation if you wanted to.
– James Sneeringer
Dec 14 at 23:04
add a comment |
I see what you're saying. Sosshd/cronddon't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?
– UtahJarhead
Dec 14 at 22:42
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of thepasswdcommand. It's not limited to just the shell, though, since you could callpasswdfrom a script through non-interactive automation if you wanted to.
– James Sneeringer
Dec 14 at 23:04
I see what you're saying. So
sshd/crond don't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?– UtahJarhead
Dec 14 at 22:42
I see what you're saying. So
sshd/crond don't need it because the history is only ever called when changing the password, which will only be happening at the shell. Does that sound correct?– UtahJarhead
Dec 14 at 22:42
1
1
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of the
passwd command. It's not limited to just the shell, though, since you could call passwd from a script through non-interactive automation if you wanted to.– James Sneeringer
Dec 14 at 23:04
Correct, mostly. You only care about old passwords when you need to compare them to a new one you want to use. The STIG correctly modifies the only file that is needed in order to apply this policy to invocations of the
passwd command. It's not limited to just the shell, though, since you could call passwd from a script through non-interactive automation if you wanted to.– James Sneeringer
Dec 14 at 23:04
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f488069%2fpassword-history-restrictions-are-written-to-in-system-auth-ac-but-not-passwo%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown