Scott Spyrison wrote:
> Hello
>
> I have been testing pam.conf with pam_ldap on build 61 of opensolaris, and
> have come up with two questions. I'm only looking to use the authentication
> part of pam, not account management/naming services. In other words, I've
> got my local accounts with usernames that correspond to uid values in an
> LDAP. I want to allow those accounts to auth with the LDAP credential. My
> nsswitch.conf file does not contain ldap as a source of information.
>
> Based on the S10 naming service docs, I cam up with the following pam stack:
>
> other auth requisite pam_authtok_get.so.1
> other auth required pam_dhkeys.so.1
> other auth required pam_unix_cred.so.1
> other auth sufficient pam_unix_auth.so.1
> other auth required pam_ldap.so.1
> ...
>
> For the most part, works as expected and I'm happy. Now onto the two
> questions I've come up with while testing...
>
> 1) No password accounts (passwd -N foousr resulting in NP in /etc/shadow) do
> not work as I thought they would. They are still allowed to login if they
> supply the correct LDAP credential. Users that are locked with *LK* in the
> shadow file are not allowed to login as expected.
That is correct behaviour based on the PAM stack you have above. NP
means 'Not Participating' in UNIX crypt(3c)/strcmp based authentication.
It is used for accounts that can login (and/or run cronjobs) rather
than those that are locked. So you are getting exactly the correct
behaviour.
This is because pam_unix_auth will return a failure but that module is
marked as sufficient.
The definition in pam.conf(4) is:
sufficient If the service module return success and no
preceding required modules returned failures,
immediately return success without calling any
subsequent modules. If a failure is returned,
treat the failure as an optional module
failure, and continue to process the PAM
stack.
So what is happening here is that the failure, because the NP, in
pam_unix_auth is ignored since we pretend that module is optional.
The reason this works is because it two fold, 1) the crypt(3C)/strcmp
will always fail for NP and *LK* 2) in pam_unix_acct we have an explicit
check for *LK* as a prefix to any hashed password so regarless of what
happened in the auth stack the account stack rejects the user.
> 2) lock_after_retries. On my test box I had this enabled for 3 failed
> logins. What I found was, even if I supply a valid LDAP credential, the
> failed login counter is incremented in the shadow file due to the
> pam_unix_auth touch. Therefore, 2 successful and valid logins using pam_ldap
> actually resulted in a failed login count of 2 for the user. I was able to
> work-around this in testing by either:
lock_after_retires works only with local files.
This is where the use of LDAP as an authorisation service is getting
"confused" with the using files as the nameservice.
What behaviour are you looking for here ? How would you like this to work ?
> a) adding nolock as an option to pam_unix_auth (which effectively disables
> lock_after_retries anyway, so why not just disable it if doing this)
> b) adding lock_after_retries=no to specific users in /etc/user_attr
>
> Am I using pam_ldap in a way it wasn't designed and are 1 and 2 above
> expected behavior?
I would say yes you are using it in a way that is outside of the normal
intended configuration, however I think it can be made to work.
I believe we only test pam_ldap when also having ldap in nsswitch.
Why are you keeping the accounts in local files but wanting to use LDAP
for authentication ?
I think this might be more like what you want:
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_ldap.so.1
other auth required pam_unix_auth.so.1
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
So what should happen here is that a successful authentication with
pam_ldap will complete the auth stack and pam_unix_auth won't be run at
all. For local only accounts like root pam_ldap will fail but that will
be ignored if pam_unix_auth succeeds. The account stack will ensure
that *LK* accounts aren't able to login at all but NP accounts will.
If you don't want an account to be able to login at all it should be
*LK* (passwd -l) not NP (passwd -N).
--
Darren J Moffat
