Hi Darren, Thanks for the feedback. Makes sense now that lock_after_retries only applies to files, and if using ldap for authorization then ldap will introduce it's own password aging/locking mechanism independent of files.
> What behavior are you looking for here ? How would > you like this to work ? The intent was to provide the opposite of what you suggested :-) In other words, have pam_unix_auth (local account) checked first, and pam_ldap checked if the local account did not succeed. That being said, I can't for the life of me tell you why I haven't swapped them around and tried pam_ldap as sufficient and pam_unix_auth as required. As I understand things, that would remove the two self-inflicted problems I described in my prior post. > Why are you keeping the accounts in local files but > wanting to use LDAP for authentication ? No good reason. Only because the larger question of using LDAP for accounts/authorization is too large for this particular project, in which the requirement is only that users be able to authenticate using an ldap id/cred. i.e. the directive being go forth and make this work but don't try and solve the world's problems with it. > If you don't want an account to be able to login at > all it should be > *LK* (passwd -l) not NP (passwd -N). I have to say i'm confused about this. My prior understanding of *LK* and NP was that: 1) *LK* prohibited login and execution of scheduled jobs via cron/at 2) NP prohibited login but allowed execution of scheduled jobs via cron/at When I test on my workstation with an account coded as NP, I can not login. In practice, I actually do as you suggest and *LK* un-used accounts (as does JASS). I always thought that NP was used for those accounts you wanted to lock, but still needed to run scheduled tasks. best, Scott This message posted from opensolaris.org
