The Picture is linked to the W10 Forum so i can't view the trace correctly.
But what i can tell you:
1) NTLM is expected when you are connecting by IP since you are unable to do Kerberos-authentication IP-based (only names Count)
2) STATUS_MORE_PROCESSING_REQUIRED is no ERROR. This is a Status message. Our friends from Microsoft like to use ERROR codes for Status Messaging in SMB. In Fact this is just part of the handshake.
what i can't see in the Connection is a session Setup Response after the "more processing required". but there may be a Problem with the wireshark Display which hides that.
There are also AD-Settings (like don't allow NTLM) that could cause this.
For what i can see i would state the following:
1) There are some TCP Retransmissions and duplicate ack. Unless you are already heavy loaded in network-traffic this should not be the case and may impact Performance (tcp slowstart etc.). But this ain't our problem here.
2) The user does not get authenticated. After paket 15 there is no Session Setup Response from the server. The paketsize is only 58Byte so the paket only shown as TCP is too small to be that paket.
this is at least strange since i would expect either a positive or a negative response.
What you can do:
a) Inspect the Session Setup Requests if the data included there is valid
b) Try to query users of the problematic domain from isilon side
c) in the screenshot there is only the SHORTNAME of the Domain included (REMOTEOFFICE) not the FQDN. Try to connect by explicitly using the upn (firstname.lastname@example.org) to prevent isilon from having problems matching REMOTEOFFICE to REMOTEOFFICE.CORP.BPO.COM.PH
a) We've checked the setup session request and it is valid.
b) We actually have a problem with mapping remoteoffice.corp.bpi.com.ph domain users. We cannot map them even though there is a trust between headoffice.corp.bpi.com.ph and the remoteoffice. We used command below to check mapping:
# isi auth users list --domain=remoteoffice.corp.bpi.com.ph
But we can list users from headoffice domain.
since im not good with that domain-trust-stuff i would do the following
setup an pakettrace at isilon (isi_for_array -s tcpdump <insert params here>) and try to connect with a remoteoffice user. Then look into the chat of isilon whith the dcs and try to figure the problem out.
This works best, if the isilon is "unloaded" so you don't get disturbed by any other users.
Also it may be necessary to use a "fresh" user, since isilon does some caching (even though if the isilon can't find a user, it should not cache anything...)
(i would not recommend to post paketcaptures of that up here...)
Wait you're saying you have issues mapping the "domain users" group from a trusted domain? Make sure you understand the type of security groups that you're using, or attempting to use. Are they domain local's, global's, etc?
For Reference from Microsoft:
If you look at it another way, can you do an 'isi auth mapping token domain\\username --zone=accesszone' of the user that you're testing with? Does that at least come back properly?
Did you ever find the cause/solution for this problem? We are experiencing the same issue with not being able to lookup/map users that don't exist in the domain configured for an access zone but there is a full trust between the two domains.