[Samba] sssd problems after dc1 is no longer online

[steve]

On Wed, 2014-07-23 at 21:24 +0200, mourik jan heupink - merit wrote:
> Hi all,
> 
> I hope that this request for help will be the last one, for a while to 
> come. Today, sernet support helped my sort out our DC mess, and they did 
> a great job. However, sssd no longer works, and I hope someone here can 
> help out.
> 
> We used to have DC1, DC2 and DC3. DC1 was the classic-upgraded, first, 
> 'original' DC, and had to be shutdown, unfortunately. So only DC2 and 
> DC3 remain.
> 
> The domain seems to work nicely, however, sssd doesn't find my users 
> anymore.
> 
> Here is a debug_level 8 log: http://pastebin.com/hRwNjRyh
> 
> Could someone tell me where the problem is? I'm guessing this logline is 
> not good:
> 
> (Wed Jul 23 21:04:44 2014) [sssd[be[default]]] [sdap_get_tgt_recv] 
> (0x0400): Child responded: 0 
> [FILE:/var/lib/sss/db/ccache_SAMBA.COMPANY.COM], expired on [1406178284]
> 
> But:
> root at epo:/var/log/sssd# kinit -k -t /etc/krb5.sssd.keytab 
> 'EPO$@SAMBA.COMPANY.COM'
> 
> root at epo:/var/log/sssd# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: EPO$@SAMBA.COMPANY.COM
> 
> Valid starting    Expires           Service principal
> 23/07/2014 21:03  24/07/2014 07:03 
> krbtgt/SAMBA.COMPANY.COM at SAMBA.COMPANY.COM
>          renew until 24/07/2014 21:03
> 
> Also: kinit heupink, asks for my password, and creates a ticket 
> successfully.
> 
> So, many things seem to work... But logging on (over ssh or remote 
> desktop) does not. Auth.log tells me:
> Jul 23 21:04:44 epo sssd_be: canonuserfunc error -7
> Jul 23 21:04:44 epo sssd_be: _sasl_plugin_load failed on 
> sasl_canonuser_init for plugin: ldapdb
> Jul 23 21:04:44 epo sssd_be: GSSAPI Error: Unspecified GSS failure. 
> Minor code may provide more information (Server not found in Kerberos 
> database)
> Jul 23 21:04:47 epo xrdp-sesman: pam_unix(xrdp-sesman:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=heupink
> Jul 23 21:04:47 epo xrdp-sesman: pam_sss(xrdp-sesman:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=heupink
> Jul 23 21:04:47 epo xrdp-sesman: pam_sss(xrdp-sesman:auth): received for 
> user heupink: 9 (Authentication service cannot retrieve authentication info)
> 
> Finally, here is my sssd.conf:
> [sssd]
> services = nss, pam
> config_file_version = 2
> domains = default
> 
> # enable or disable the below
> # debug_level = 3
> # debug_level = 5
> debug_level = 8
> [nss]
> 
> [pam]
> 
> [domain/default]
> debug_level = 8
> 
> ldap_schema = rfc2307bis
> id_provider = ldap
> access_provider = simple
> ldap_referrals = false
> ldap_force_upper_case_realm = true
> 
> # on large directories, you may want to disable enumeration for 
> performance reasons
> # enumerate = true
> 
> auth_provider = krb5
> chpass_provider = krb5
> ldap_sasl_mech = gssapi
> ldap_sasl_authid = EPO$@SAMBA.COMPANY.COM
> krb5_realm = SAMBA.COMPANY.COM
> #krb5_server = dc2.samba.company.com, dc3.samba.company.com
> krb5_server = x.y.143.15, x.y.143.16
> #krb5_kpasswd = dc2.samba.company.com, dc3.samba.company.com
> krb5_kpasswd = x.y.143.15, x.y.143.16
> ldap_krb5_keytab = /etc/krb5.sssd.keytab
> ldap_krb5_init_creds = true

Hi
1. Unless you have a reverse zone and your x.y.143.15 and ....16 resolve
properly, use the fqdn.
> 
> ldap_uri = ldap://x.y.143.15, ldap://x.y.143.16
> ldap_search_base = dc=samba,dc=merit,dc=unu,dc=edu
For AD objects, this doesn't make sense. This domain does not correspond
to anything in your realm. I could believe:
ldap_search_base = cn=Users,dc=samba,dc=company,dc=com
but I see no connection with samba.merit.unu.edu
But it's late, too hot and everyone else has gone for a beer so we may
well have missed something earlier in the thread.

> 
> ldap_user_object_class = user
> ldap_user_name = samAccountName
> ldap_user_uid_number = uidNumber
> ldap_user_gid_number = gidNumber
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_shell = loginShell
> 
> ldap_group_object_class = group
> ldap_group_name = cn
> ldap_group_member = member
> 
> I hope this is enough info, and one of the sssd guru's here can assist. 
> Again: everything worked while dc1 was online, things stopped working 
> when it was taken offline.

Maybe, but for AD I'd really recommend switching to sssd with a proper
AD backend whwreupon you can forget about DNS. All the 1.11 series have
it, as does the latest 1.12.0. the configuration is simple and when the
cache is full it absolutely screams:
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[domain/default]
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = False

For the usual gotchas in a S4 domain:
http://linuxcostablanca.blogspot.com.es/2014/04/sssd-ad-backend-with-samba4.html

HTH,
Steve