Tomas Mraz wrote:
- For some reason, pam_ldap interacts strangely with pam_unix.
Even tough pam_unix comes before it and is "sufficient",
nobody can login when the network is down or slapd is down.
The pam_ldap module will reject login in the account phase. You can use
pam_localuser (supported by authconfig) to make pam_unix authorization
of local users sufficient.
Thank you. I've regenerated my /etc/pam.d/system-auth with
system-config-authentication and enabled the localuser module.
Login with local user accounts still failed because nss_ldap
tries too hard to connect to the LDAP server and incurs in
the 60 seconds timeout of /bin/login.
I've fixed it by setting these options in my /etc/ldap.conf:
# Search timelimit
timelimit 3
# Bind timelimit
bind_timelimit 2
# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
bind_policy soft
I wonder if values like these should become the Fedora defaults?
A system that just hangs when you pull the ethernet cable doesn't
make a good impression with most users.
Also, you can login as root with root's password from ldap
even tough there's a valid root entry in /etc/passwd.
That's expected as both pam_ldap and pam_unix are sufficient entries.
If you want to prevent that you can insert pam_succeed_if
Sorry, I don't quite understand how to set it up to reject uid == 0
just for pam_ldap and not for pam_unix.
I also don't understand what the "uid < 100" condition inserted
by system-config-auth is for.
My current config is:
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5afs.so use_first_pass tokens
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account [default=bad success=ok user_unknown=ignore] pam_krb5afs.so
account required pam_permit.so
password requisite pam_cracklib.so retry=3
password sufficient pam_unix.so md5 shadow nullok use_authtok
password sufficient pam_krb5afs.so use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
session optional pam_krb5afs.so
session optional pam_ldap.so
The man pam_succeed_if man-page says it can suceed _or_ fail,
but it only seems to
- Many pam.d files still use the absolute path "/lib/security/$ISA/"
that doesn't seem to be useful anymore and looks weird on
bi-arch systems such as x86_64.
They will be converted during the change to use include instead of
pam_stack.
Nice. system-config-authentication already wiped the paths out
when it rewrote system-auth.
- Something similar of pam_ssh would be much cleaner than the
current hack of running ssh-agent in GDM's session. gpg-agent
support would also be welcome.
This is a problem as the passphrases for ssh keys can be different from
the user's system password. So the pam_ssh is definitely not a
replacement for ssh-agent.
Yes, we would need half of what pam_ssh does: instead of authenticating
the user against his ssh key, it should just load the key iff the
passphrase happens to match the account password.
Maybe this other project would be more appropriate:
http://sourceforge.net/projects/pam-ssh-agent/
PAM module that spawns a ssh-agent and adds identities using the
password supplied at login.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
