2012-04-11 08:22 AM
I would like to remind about the port requirement ... CIFS uses UDP ports 137 and 138, and TCP ports 139 and 445. The filer sends and receives data on these ports while providing CIFS service. If it is a member of an Active Directory domain, the filer also must make outbound connections destined for DNS (Port 53 UDP and TCP) and Kerberos (Port 88 and 464). Incoming Port 137 - NBNS - (UDP) we listen for name queries and respond if we recognize ours. Outgoing Port 137 - NBNS - (UDP) we are a client of the name service. Outgoing Port 138 - NBDS - (UDP) we are a client of the datagram service. Incoming Port 139 - NBSS - (TCP) CIFS server. Incoming Port 445 - CIFS over TCP (TCP) CIFS server. Outgoing Port 139 - NBSS - (TCP) Cifs client (for contacting DC, virus scanners, etc.). Outgoing Port 445 - (TCP) Same as outgoing 139, above. Outgoing Port 88 - (TCP, maybe UDP) Kerberos Outgoing Port 464 - (TCP, maybe UDP) Kerberos Key administration
2012-04-11 09:21 AM
Without a trust or a local account on the NetApp the other domain won't have access. Another method is to create the same username on both domains with the same password then have pass through that way (works with a local account that matches the domain user name/password too). This isn't a Netapp issue but security..you can get around it with the methods listed but multiple domains should be looked at for security (why are there multiple and is it ok by company rules to share like this). You could also create a vFiler and join it to the other domain...then flexclone or mirror over loopback on the controller the volume which contains the share then give access..another brute force workaround but an option if you need regular access to a software repository or something similar.