Mark, Probe with this line: authconfig --enablelocauthorize --updateall Regards, Alejandro www.linuxiso.com.ar Argentina 2008/8/27 Mark Hennessy <mark at hennessy.cx> > Quoting Craig White <craigwhite at azapple.com>: > > On Wed, 2008-08-27 at 20:41 -0400, Mark Hennessy wrote: >> >>> Quoting Craig White <craigwhite at azapple.com>: >>> >>> > On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote: >>> >> Quoting Craig White <craigwhite at azapple.com>: >>> > >>> >> > well, it hardly makes any sense to use ldap for user accounts and >>> start >>> >> > up with networking off but I would recommend that you adhere to the >>> >> > advice at the top of the file and run 'authconfig' or >>> >> > 'system-config-authentication', make sure the settings are correct >>> >> > (including checking the box for local authentication is sufficient) >>> so >>> >> > that it configures not only /etc/pam.d/system-auth and nsswitch.conf >>> >> >>> >> Yes, I agree, it makes no sense to operate a machine with ldap >>> >> accounts if it has no network connection, but at least one should be >>> >> able to log in as root. To clarify, here's the problem: >>> >> I have a machine. In normal operation, the network connection is >>> >> non-functional and LDAP accounts are usable and everyone does their >>> >> thing over ssh. If the network connection craps out, I can get into >>> >> the machine via serial console and try to find out what's going on, >>> >> perhaps switch to a different network connection, whatever. If I >>> >> can't log in as root, my only recourse is to powercycle the machine >>> >> and go into single-user mode. Now, multiply that by 100. This is why >>> >> I need to get this working. >>> > ---- >>> > sounds like you're trying to fix a symptom, not the problem. >>> > >>> > anyway, did you run authconfig/system-config-authentication ? >>> >>> Yes, I did in fact run it. >>> here are the results: >>> authconfig --enableldap --enableldapauth --ldapserver=ldap.example.com >>> --enableldaptls >>> --ldaploadcacert=file:///etc/openldap/cacerts/cacert.pem --test >>> >>> caching is enabled >>> nss_files is always enabled >>> nss_compat is enabled >>> nss_db is disabled >>> nss_hesiod is disabled >>> hesiod LHS = "" >>> hesiod RHS = "" >>> nss_ldap is enabled >>> LDAP+TLS is enabled >>> LDAP server = "ldap.example.com" >>> LDAP base DN = "dc=example,dc=com" >>> nss_nis is disabled >>> NIS server = "" >>> NIS domain = "" >>> nss_nisplus is disabled >>> nss_winbind is disabled >>> SMB workgroup = "WORKGROUP" >>> SMB servers = "" >>> SMB security = "user" >>> SMB realm = "" >>> Winbind template shell = "/bin/false" >>> SMB idmap uid = "blah-blah" >>> SMB idmap gid = "blah-blah" >>> nss_wins is disabled >>> pam_unix is always enabled >>> shadow passwords are enabled >>> md5 passwords are enabled >>> pam_krb5 is disabled >>> krb5 realm = "EXAMPLE.COM" >>> krb5 realm via dns is disabled >>> krb5 kdc = "kerberos.example.com:88" >>> krb5 kdc via dns is disabled >>> krb5 admin server = "kerberos.example.com:749" >>> pam_ldap is enabled >>> >>> LDAP+TLS is enabled >>> LDAP server = "ldap.example.com" >>> LDAP base DN = "dc=example,dc=com" >>> pam_pkcs11 is disabled >>> >>> use only smartcard for login is disabled >>> smartcard module = "coolkey" >>> smartcard removal action = "Ignore" >>> pam_smb_auth is disabled >>> SMB workgroup = "WORKGROUP" >>> SMB servers = "" >>> pam_winbind is disabled >>> SMB workgroup = "WORKGROUP" >>> SMB servers = "" >>> SMB security = "user" >>> SMB realm = "" >>> pam_cracklib is enabled (try_first_pass retry=3 debug) >>> pam_passwdqc is disabled () >>> Always authorize local users is disabled () >>> Authenticate system accounts against network services is disabled >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> These last two lines look interesting. >>> >> ---- >> I would think that authenticate system accounts against network services >> is disabled would be the setting that you want but the other... >> >> always authorize local users should be enabled. >> >> Also, I'm assuming that you've swapped out dc=example,dc=com for the >> real entries and will put in the real entries when you actually run the >> command. >> > > Your assumption is valid, and, in this case, correct. > > After running that, I ran authconfig-tui and followed the prompts, > including making local login sufficient, and then performed the test. It > failed with the same issue, password accepted without claim of failure, no > shell, new login prompt. > > > >> Craig >> >> > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20080827/a9a3a338/attachment-0004.html>