Re: nsswitch.conf, ldap, local groups problem

[Mark Hennessy <mark@xxxxxxxxxxx>]

Quoting Craig White <craigwhite@xxxxxxxxxxx>:

> On Wed, 2008-08-27 at 20:41 -0400, Mark Hennessy wrote:
> > Quoting Craig White <craigwhite@xxxxxxxxxxx>:
> >
> > > On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
> > >> Quoting Craig White <craigwhite@xxxxxxxxxxx>:
> > >
> > >> > 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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos