Error No matching domain found for 5001 in sssd_nss.log
sgallagh at redhat.com
Mon Jul 19 14:20:57 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 07/11/2010 01:08 AM, John Nissley wrote:
> I will admit that getting fedora 13 to authenticate against my dirsrv
> ldap server has been an interesting experience. I still do not think I
> have it right since getent passwd does not display the ldap users but
> for some reason I am able to log in with my ldap user name and password
> and the home directory mapping is pulled out of ldap.
By default, SSSD does not return answers to 'getpwent' requests, only
'getpwuid' and 'getpwnam' (and the group equivalents). This is to avoid
returning ridiculous numbers of replies from very large deployments.
If you want this behavior, add 'enumerate=true' to the
[domain/<yourdomain>] section in /etc/sssd/sssd.conf (<yourdomain> is
usually 'default', unless you created it manually)
> This error is in my sssd.nss.log file after reboot when I try to log in.
> [sssd[nss]] [nss_cmd_getgrgid_callback] (0): No matching domain found
> for , fail!
> The interesting thing is that the uid for the user trying to
> authenticate is 5001 so that must be coming back from the ldap server.
Note the error message. It's performing a getgrgid request, not a
getpwuid request. That means that it's looking for a group in ldap with
the same ID (5001) that it cannot find. Probably this means that your
user is specified as having UID=5001, primary GID=5001, but LDAP doesn't
actually have a group stored with GID=5001
> Can some on please help me straighten out my network login via ldap
> problem I am having. I was doing the same network login to the same
> ldap server with Fedora 12 and had no issues at all. Fedora 13 requires
> tls or ldaps which is where my problems started. I was not using either
> of them when using Fedora 12.
SSSD doesn't allow you to perform authentication without using TLS or
LDAPS because doing so sends your password unencrypted over the
internet. The old way of doing things - nss_ldap - used to allow this.
When we developed the SSSD we decided to be more strict, since no good
can come of allowing unencrypted passwords on the wire.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the users