Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to understand what's behaving errantly on my PAM configuration on FreeBSD 10.0

The machine is configured with two different authentication realms, one is the default Unix authentication and the other one is using the System Security Services Daemon (sssd).

At this moment I'm using this configuration in /etc/pam.d/sshd since I just want to allow sssd logins from ssh.

auth            sufficient                  no_warn no_fake_prompts
auth            requisite            no_warn allow_local
auth            sufficient      /usr/local/lib/
#auth           sufficient                  no_warn try_first_pass
#auth           sufficient                   no_warn try_first_pass
auth            required                  no_warn use_first_pass

# account
account         required
#account        required
account         required
account         required        /usr/local/lib/    ignore_unknown_user
account         required

# session
#session        optional                   want_agent
session         optional        /usr/local/lib/
session         optional        /usr/local/lib/      mode=0700
session         required

# password
password        sufficient      /usr/local/lib/    use_authtok
#password       sufficient                  no_warn try_first_pass
password        required                  no_warn try_first_pass

If I understood correctly, when a sssd user logs on the machine it will hit the auth sufficient /usr/local/lib/ line and since this is sufficientit will login without any problems. When a local user account tries to login it will fail in the sssd check but will succeed in using the password entered for the first time, without asking for the password again.

But it's not what's happening. To successfully login as a local account, I must remove use_first_pass from optiions in auth realm and when the user logins, the system first asks for the sssd account, failing since the local users doesn't exists in the external authentication service. Then the system asks again for the same password, but authenticating on the module. And finally the access is granted.

As example, it behaves in this manner:

ssh -l local-user-account
Password for
Last login: Sat May 24 16:22:40 2014 from
FreeBSD 10.0-RELEASE-p1 (GENERIC) #0: Tue Apr  8 06:45:06 UTC 2014

Welcome to FreeBSD!


I don't exactly why this happens or if it has something to do with the account session. As for my understand about PAM, the configuration should be right.

Thanks in advance,

share|improve this question
up vote 3 down vote accepted

Well my premises about the workings of PAM were right.

The module was expecting the argument forward_pass to relay to password for other PAM modules, as the pam_unix.somodule. So just putting this option do the job. The resultant line was:

auth            sufficient      /usr/local/lib/           forward_pass

Which ended in another problem. If sssd or even then authentication realm of sssd are down you'll be unable to login, since the module will no work as and consequently the password will not be forwarded.

So the obvious choice was to put before and let everything be "sufficient" with a nicely at the end. That's the Linux way to solve to problem, but this does not appears to work on FreeBSD.

After some googling through mailing lists the proper way to do this on FreeBSD is using the strange order in PAM:

auth            sufficient                 no_warn no_fake_prompts
auth            requisite           no_warn allow_local
auth            sufficient                 no_warn
auth            sufficient      /usr/local/lib/   use_first_pass
auth            required                 no_warn use_first_pass

So putting two times in PAM, the first one as sufficient and the last one as required do the trick. I don't know why this happens but it's working and appears to be right way to do.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.