- Isilon OneFS8.0 joined to headoffice.corp.com.ph
- Isilon is joined to headoffice.corp.bpi.com.ph with 2-way trust-relationship to remoteoffice.corp.com.ph
- 10.134.16.94 is SSIP
Before migration, at VNX side, users from both domain can access the share and directories. After migration, at Isilon side, users from headoffice domain only can access the shares.
User is trying to access \\10.134.16.94\<Share>. We also tried Isilon Node IP \\10.134.16.70\<Share>.
“a device attached to the system is not functioning"
Here are the troubleshooting activities that we've done already:
1. Firewall ports from Isilon to Active Directory headoffice and remoteoffice are enabled and tested successfully.
tcp 88 for Kerberos
tcp 389 for LDAP
tcp 445 for SMB
tcp 464 for Kerberos Machine Password
udp 53 for DNS
tcp 3268 for AD global catalog
tcp 3269 for AD global catalog
2. Trust-relationship between two domains are confirmed. Below commands are successfully executed by the affected user.
3. Below command was successfully executed from Domain Controller.
In headoffice DC:
C:\>nltest /whowill:headoffice.corp.bpi.com.ph ibmfm-beilagan
In remoteoffice DC:
C:\>nltest /whowill:remoteoffice.corp.bpi.com.ph mecuizonj
Both results are "ACT FOUND".
4. TCP Port 445 is already opened from Workstation to Isilon IP Addresses.
We're running out of troubleshooting technique to do. Appreciate any help.
There was a similar thread recently that may also prove useful:Re: Clients autheticating on nodes 2 & 3 get error message "A device attached to the system is n...
There are a couple processes on the Isilon cluster that could be verified are running. You may be able to save some time by working directly with Isilon Support. If you haven't already opened a service request, you can do so here: https://onlinesupport.emc.com/SRCreate
Thanks for your reply. I've opened an SR and it's still on process for weeks now. We almost have the same issue but for ours, the error prompts when trying to connect to ALL NODES. We've resolved the time issue and all synced now.
Is opening TCP port 445 enough from Workstation to Isilon aside from opening ports above from Isilon to Active Directory Provider?
I'm wondering if we need to define an A record of the trusted domain in the headoffice domain server and if we also need to add an FQDN equivalent to remoteoffice in Isilon. Is it enough that since trust is established between two domains, there will be no configuration in Isilon side? Thanks.
I think most of your questions regarding port settings can be answered within the security documentation.
8.0.0 Security Configuration Guide
8.0.1 Security Configuration Guide
In terms of DNS setup, that really depends on the environment. Typically, DNS is integrated in AD so necessary DNS components and records are added as such. If the trust is another FOREST with another DNS infrastructure, then you will need to have the proper DNS setup on the cluster. If you trust the other domain, you should probably have an NS/Delegation pointing to that forest DNS.
In our environment, the TRUST-RELATIONSHIP is with another FOREST with another DNS Infrastructure.
DNS servers for HEADOFFICE.CORP.BPI.COM.PH
DNS servers for REMOTEOFFICE.CORP.BPI.COM.PH
DNS configuration was done in HEADOFFICE.CORP.BPI.COM.PH.
A Record - pdcnas - 10.134.16.94
NS - pdcnas1 - pointing to A record 10.134.16.94
In Isilon, below is the configuration:
SSIP - 10.134.16.94
Pool1 FQDN - pdcnas1.headoffice.corp.bpi.com.ph
Should we add configurations in Isilon and DNS even if there is trust? Isn't it that it should resolve automatically?
We had packet captures and see below result. Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE was the error from Isilon SSIP. The client then replied with its DOMAIN\username and the Isilon replied with ACK. After that, RESET was sent by Workstation IP. Is this a workstation related problem?
I found a thread related to this and it seems like a workstation error. I'll check if the workstation OS was Windows10.
Users should never be connecting to the SSIP for file services. Although it may work, they should be connecting to an IP in a SmartConnect zone associated with an access zone in which the data resides.
I agree. We let the client connect to SSIP and Node IP Addresses first because we are isolating the issue. We want to omit the name resolution/dns in the picture thus we used IP Address. We want to check if it is with Network Routing, Workstation or Isilon that's causing the error.