On Fri, Aug 12, 2016 at 02:55:16PM -0000, thomas.beaudry(a)concordia.ca wrote:
Hi,
So I didn't have a DNS issue, so i figured to just restart the install process from
scratch (since i had originally tried setting up winbind and some other stuff). Now i
didn't need to add [appdefaults] and it just worked when i use realm join. My new
problem is that I can ssh but I can't su. When i do a su to either a local or AD
user, I get:
su: Permission denied
What am I missing? Here are my child and domain logs:
sssd_concordia.ca.log:
http://pastebin.com/raw/eD2b01bn
krb5_child.log:
http://pastebin.com/raw/T42m5EeD
ldap_child.log:
http://pastebin.com/raw/WpvEetUY
su from root only works because pam_rootok is normally in the stack so
sssd authentication is bypassed.
It's still the same error:
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [ad_sasl_log] (0x0040): SASL: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information (Server not found
in Kerberos database)
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [sasl_bind_send] (0x0020):
ldap_sasl_bind failed (-2)[Local error]
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [sasl_bind_send] (0x0080): Extended
failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Server not found in Kerberos database)]
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [_be_fo_set_port_status] (0x8000):
Setting status: PORT_NOT_WORKING. Called from:
../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2039
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [fo_set_port_status] (0x0100): Marking
port 389 of server 'int-con-dc-2.concordia.ca' as 'not working'
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [fo_set_port_status] (0x0400): Marking
port 389 of duplicate server 'int-con-dc-2.concordia.ca' as 'not working'
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [sdap_handle_release] (0x2000): Trace:
sh[0x22fe410], connected[1], ops[(nil)], ldap[0x22feaf0], destructor_lock[0],
release_memory[0]
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [remove_connection_callback] (0x4000):
Successfully removed connection callback.
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [check_online_callback] (0x0100):
Backend returned: (3, 0, <NULL>) [Internal Error]
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [fo_reset_services] (0x1000):
Resetting all servers in all services
Here SSSD is trying to talk to this DC:
(Fri Aug 12 10:47:27 2016) [sssd[be[concordia.ca]]] [sdap_ldap_connect_callback_add]
(0x1000): New LDAP connection to [ldap://int-con-dc-2.concordia.ca:389/??base] with fd
[22].
Is it the right one? Can you kinit from that machine with a keytab and
try to search that DC manually, adding KRB_TRACE before the ldapsearch
command to see more debug output from the libkrb5?