Created attachment 827403 [details]
Http error logs with samba log level 100

Description of problem:
Re-adding a trust that already exists fails with error
"ipa: ERROR: CIFS server communication error: code "-1073741811",
                  message "Unexpected information received" (both may be "None")"


Version-Release number of selected component (if applicable):
ipa-server-trust-ad-3.3.3-4.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Add trust with an AD server
2. Repeat trust-add with same AD server

Actual results:
[root@rhel7-b ~]# cat /usr/share/ipa/smb.conf.empty
[global]
log level = 100

[root@rhel7-b ~]# /usr/bin/ipa trust-add --type=ad adtest.qe --admin Administrator --password
Active directory domain administrator's password:
------------------------------------------
Re-established trust to domain "adtest.qe"
------------------------------------------
  Realm name: adtest.qe
  Domain NetBIOS name: ADTEST
  Domain Security Identifier: S-1-5-21-1910160501-511572375-3625658879
  SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16,
                          S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16,
                          S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

[root@rhel7-b ~]# /usr/bin/ipa trust-add --type=ad adtest.qe --admin Administrator --password
Active directory domain administrator's password:
ipa: ERROR: CIFS server communication error: code "-1073741811",
                  message "Unexpected information received" (both may be "None")

Expected results:
Trust is re-established without any errors

Additional info:
Pasting ab's investigation from email

Ok, according to the logs this is one of cases where we should wait a
bit to allow KDC to refresh list of trusted domains before we go to the
AD DC to fetch its forest topology information:

Starting GENSEC mechanism spnego
Starting GENSEC submechanism gssapi_krb5
Ticket in credentials cache for @TESTRELM will expire in 86399 secs
Server cifs/ad12srv1.adtest.qe@ is not registered with our KDC:
Unspecified GSS failure.  Minor code may provide more information:
Server krbtgt/ADTEST.QE not found in Kerberos database
SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_INVALID_PARAMETER
SPNEGO: Could not find a suitable mechtype in NEG_TOKEN_INIT
Failed initial gensec_update with mechanism spnego:
NT_STATUS_INVALID_PARAMETER

We already force KDC to refresh but some race could still be there, I
guess.