6

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 pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_sss.so #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn use_first_pass # account account required pam_nologin.so #account required pam_krb5.so account required pam_login_access.so account required /usr/local/lib/pam_sss.so ignore_unknown_user account required pam_unix.so # session #session optional pam_ssh.so want_agent session optional /usr/local/lib/pam_sss.so session optional /usr/local/lib/pam_mkhomedir.so mode=0700 session required pam_permit.so # password password sufficient /usr/local/lib/pam_sss.so use_authtok #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so 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/pam_sss.so 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 pam_unix.so 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 pam_unix.so 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 pam_unix.so module. And finally the access is granted.

As example, it behaves in this manner:

ssh sssd-test.example.com -l local-user-account Password: Password for [email protected]: Last login: Sat May 24 16:22:40 2014 from 192.168.1.100 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,

1 Answer 1

6

Well my premises about the workings of PAM were right.

The pam_sss.so 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/pam_sss.so 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 pam_sss.so module will no work as and consequently the password will not be forwarded.

So the obvious choice was to put pam_unix.so before pam_sss.so and let everything be "sufficient" with a nicely pam_deny.so 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 pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient pam_unix.so no_warn auth sufficient /usr/local/lib/pam_sss.so use_first_pass auth required pam_unix.so no_warn use_first_pass 

So putting pam_unix.so 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.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.