On Tue, Apr 23, 2013 at 10:00 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue 23 Apr 2013 12:55:19 PM EDT, Brandon Foster wrote:
> hey all, Im new to sssd and ldap so be gentle =)
>
> I've followed some guides on how to set up sssd ldap client
> authentication on Centos 6.3 but mine doesnt seem to be working
> here is my sssd.conf
>
> ----- [sssd] config_file_version = 2 services = nss, pam domains =
> default
>
> [nss] filter_users =
> root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
>
> [pam]
>
> [domain/default] auth_provider = ldap debug_level = 9 enumerate =
> True cache_credentials = True chpass_provider = ldap
> entry_cache_timeout = 600 krb5_realm =
EXAMPLE.COM krb5_server =
>
kerberos.example.com ldap_chpass_uri = ldaps://xx.xx.xx.xx:<PORT>/
> ldap_force_upper_case_realm = True id_provider = ldap
> ldap_group_member = uniquemember ldap_group_object_class = group
> ldap_id_use_start_tls = False ldap_pwd_policy = none
> ldap_search_base =
> ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=example
>
>
ldap_schema = rfc2307bis
> ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert =
> never ldap_uri = ldaps://xx.xx.xx.xx:<PORT>/ ldap_user_gecos =
> displayName ldap_user_home_directory = unixHomeDirectory
> ldap_user_name = cn ldap_user_object_class = user
>
> ------
>
> ldapsearcg -z 'cn=username' comes back with all the information
> about the user
>
> but id username takes a really long time and then returns no such
> user.
>
> here is a piece of the log:
>
...
> (Tue Apr 23 12:51:29 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs:
> [defaultNamingContext] (Tue Apr 23 12:51:29 2013)
> [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
> Requesting attrs: [lastUSN] (Tue Apr 23 12:51:29 2013)
> [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
> Requesting attrs: [highestCommittedUSN]
> ---------------------------------------------------------------------------
>
>
>
To me it looks like its searching but not finding for some reason
>
> any help would be much appreciated.
>
You truncated the log too early. It is only showing the connection to
the LDAP server (and the determination of server capabilities). Please
include the actual user search that should follow that.
I'm guessing your user might be missing something important, like
uidNumber or gidNumber (or it's stored in a non-standard attribute name).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlF2vhMACgkQeiVVYja6o6MhFwCgq5BD+hVyPfOiTZxCJ/Hyw79U
OaAAnjc9WncvDw+IofzaQUTQgtlGZcVS
=VeAV
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
hey thanks for the quick reply.
that is the end of the log after the user search has finish. the next
line after that is:
-------------------
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]] [server_setup]
(0x0400): CONFDB: /var/lib/sss/db/config.ldb
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]] [recreate_ares_channel]
(0x0100): Initializing new c-ares channel
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]]
[resolv_get_family_order] (0x1000): Lookup order: ipv4_first
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]] [fo_context_init]
(0x0400): Created new fail over context, retry timeout is 30
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]]
[confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]]
[sysdb_domain_init_internal] (0x0200): DB File for default:
/var/lib/sss/db/cache_default.ldb
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]] [ldb] (0x4000): Added
timed event "ltdb_callback": 0x10e98c0
(Tue Apr 23 12:52:29 2013) [sssd[be[default]]] [ldb] (0x4000): Added
timed event "ltdb_timeout": 0x10ff4d0
....
---------------
which is the same as the very beginning of the log.
the start of the user search is in there near the end, but that is
where the log ends when taken after the id search has failed.