On Fri, Apr 05, 2013 at 10:19:41PM -0700, Chris Gray wrote: > Sorry in advance for the most likely repeated question. After searching for > a week, and still being stuck, it was time to ask the mailing list. > > I have a CentOS 6.4 machine that I'm trying to use SSSD/LDAP/KRB5 > to authenticate with active directory. > > I can do ldapsearch commands with ldap, or ldaps (the ldap only works due > to the machine account, using GSSAPI, otherwise, my domain doesn't support > anonymous binding). > > I can kinit my username, and klist shows the host/hostname entries. > > OpenSSL doesn't complain about my certs. > > My only problem seems to be SSSD saying my ports are down. I get the same > message for 389 and 636. Once it's marked as not working, > the authentication clearly fails (first login, no cache to fall back on). > > I can telnet to the ports from the centos machine. I can telnet (well, > kitty in telnet mode) to them from my windows workstation. > > Any ideas? > > Installed versions: > sssd-1.9.2-82.4.el6_4.x86_64 > sssd-client-1.9.2-82.4.el6_4.x86_64 > openldap-2.4.23-32.el6_4.x86_64 > openldap-clients-2.4.23-32.el6_4.x86_64 > nss-3.14.0.0-12.el6.x86_64 > krb5-workstation-1.10.3-10.el6_4.1.x86_64 > pam-1.1.1-13.el6.x86_64 > kstart-4.1-2.el6.x86_64 > msktutil-0.4.2-1.el6.x86_64 > > My ldapsearch commands, > ldapsearch -H ldaps://server.fqdn:636/ -Y GSSAPI -N -b "dc=example,dc=corp" > "(&(objectClass=user)(sAMAccountName=username))" > ldapsearch -H ldaps://server.fqdn:636/ -x -b '' -s base > supportedSASLMechanisms > > Both of those work, and can work over non-tls ldap. > > openssl s_client -connect server.fqdn:636 -CAfile > /etc/openldap/certs/adpubkeycerts.pem > That command works fine. > > (Fri Apr 5 20:43:49 2013) [[sssd[ldap_child[1532]]]] > [sss_child_krb5_trace_cb] (0x4000): [1532] 1365219829.627008: Received > error from KDC: -1765328378/Client not found in Kerberos database > > (Fri Apr 5 20:43:49 2013) [sssd[be[domain.corp]]] [sdap_get_tgt_recv] > (0x0400): Child responded: 14 [Client not found in Kerberos database], > expired on [0] > (Fri Apr 5 20:43:49 2013) [sssd[be[domain.corp]]] [sdap_kinit_done] > (0x0100): Could not get TGT: 14 [Bad address] > (Fri Apr 5 20:43:49 2013) [sssd[be[domain.corp]]] [sdap_cli_kinit_done] > (0x0400): Cannot get a TGT: ret [5] result [4] >
As you figured out, the SSSD could not kinit b/c the principal it tried to kinit as didn't exist on the server. > I'm assuming those log entries are my problem. > Or not, I fixed those by adding this to sssd.conf, which doesn't seem like > it should be needed, as I would think it'd pick it up from /etc/krb5.keytab: > ldap_sasl_authid = server$@fqdn We should be picking this principal automatically, I think. What is the contents of your /etc/krb5.keytab (klist -k) ? Do the logs tell which principal SSSD attempted to use? I think the principal selection would happen right after startup. > > Well, at least that's progress, still can't login though with an AD account. > > Hopefully that's just a matter of fixing these: > (Fri Apr 5 22:11:34 2013) [sssd[be[domain.corp]]] [krb5_auth_send] > (0x0100): No ccache file for user [ADUser] found. > (Fri Apr 5 22:11:34 2013) [sssd[be[domain.corp]]] [krb5_auth_send] > (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. This is just a warning that there is no ccache file to be reused and SSSD should create a new one. Is there anything else in the logs? Maybe in /var/log/sssd/krb5_child.log ? If you raise debug level all the way to 10 the krb5 child log would contain really low level tracing information. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
