How does SnapDrive authenticate when trying to manage another server?

[#1]

When one uses SnapDrive "Add SnapDrive Server", how does SnapDrive authenicate and maintain security. Customer is trying to make sure its configured correctly. They are worried if SnapDrive is installed users can connect to other servers. Here's the simple example they provided:

User A is a local sys admin on WinServer A

User B is a local sys admin on WinServer B

SnapUser is a domain admin used for the SnapDrive Service

WinServerA &B are connecting to the same NetApp controllers and in the same window domain.

Can User A log into WinServer A, Use SnapDrive to add WinServer B and then see/modify the configurations on WinServer B?

How does SnapDrive authenticate the user when adding a snapdrive server?

Thanks,

Steve

[#2]

Via RPC by default.  Via Http or Https if you configure it that way.

[#3]

Is RPC or HTTP based on the SnapDrive Service account or the user who is logged in using the SnapDrive Gui?

I need to confirm the example I provided to make sure users can't make changes to remote server through SnapDrive.

Thanks,

Steve

[#4]

RPC is based on the service account. HTTP or HTTPS is based on a Filer local account.

[#5]

Hi,

I'm currently out of the office with no access to email. I'll be returning

to the office on 14 June.

Queries regarding patches => dl-patches@netapp.com

Queries regarding core/data automation => dl-sustools-automation@netapp.com

I'll return return any mails when I'm back in the office.

Regards,

-jenni

--

Jennifer Coopersmith

Sustaining Engineer

NetApp Global Services

NetApp

408.822.6908 Direct

510.825.5600 Mobile

jenni@netapp.com

www.netapp.com

--

Jennifer Coopersmith

Sustaining Engineer

NetApp Global Services

NetApp

408.822.6908 Direct

jenni@netapp.com

www.netapp.com

[#6]

I think i'm confused. This sounds like how the local SnapDrive agent authenticates to the NetApp controller. I'm trying to find out how SnapDrive GUI authenticates to another remote server.

From the SnapDrive GUI or plugin, I can manage another Windows server (not the one i'm logged into). How does the remote Windows Server authenticate the requests coming from the local Server? The main concern is a user who has privs on a local server but not on a remote server making configuration changes through SnapDrive.

Example:

User A is a local sys admin on WinServer A

User B is a local  sys admin on WinServer B

SnapUser is a domain admin used for the  SnapDrive Service

WinServerA &B are connecting to the same NetApp  controllers and in the same window domain.

Can User A log into WinServer A,  Use SnapDrive to add WinServer B and then see/modify the configurations  on WinServer B?

How does SnapDrive authenticate the user when  adding a snapdrive server?

[#7]

Hi,

I'm currently out of the office with no access to email. I'll be returning

to the office on 14 June.

Queries regarding patches => dl-patches@netapp.com

Queries regarding core/data automation => dl-sustools-automation@netapp.com

I'll return return any mails when I'm back in the office.

Regards,

-jenni

--

Jennifer Coopersmith

Sustaining Engineer

NetApp Global Services

NetApp

408.822.6908 Direct

510.825.5600 Mobile

jenni@netapp.com

www.netapp.com

--

Jennifer Coopersmith

Sustaining Engineer

NetApp Global Services

NetApp

408.822.6908 Direct

jenni@netapp.com

www.netapp.com

[#8]

How does Windows authentication work?  Your question really has nothing to do with NetApp.  If I have a domain account that is used as a service account on two hosts, and has permissions to a network resource, can that account running on one host alter the network resource?  Can the Blackberry service account touch two different mailboxes on the email server?  Yes.  In your case that domain user account has permissions on both local hosts as well as the network resource.

Why don't you use different service accounts on the two hosts?  Only give those accounts permissions to the specifc resources you want on the NetApp controller, and on the specif hosts you want.

J

[#9]

Thanks, I think i'm getting closer to an answer. As you state, the customer will need to have different service accounts for the different Windows Servers in their environment.

The SnapDrive Service is proxying requests between servers and is authenticating itself as the SnapDrive Service account user when it does, not the user who is logged in using the SnapDrive GUI.

Just to verify if i can explain it to the customer correctly...

Customer has multiple dev, test, and prod servers and wants to prevent a local admin on any of those servers from making changes on any other server through SnapDrive GUI. To implement this they will have to create a unique local admin account for SnapDrive service on each Windows Server. This will also prevent them taking advantage of the SnapDrive GUI managing multiple Windows Servers.

Thanks for your help!

Steve

[#10]

Whatever your windows server is a member of workgroup or domain, you can configure snapdrive (windows server) trasport protocol settings to authenticate with the storage system.

There are three types of protocols for authentication

a. RPC

b and c. HTTP or HTTPS

after that you can configure a local computer account (hostname\username) or a (domainname\username) that is local or domain administrator to the storage system.

For a Domain User service account that runs with SnapDrive, CIFS must be enabled and configured in the storage with the domain for your network.

Also, be sure that the following ports are open between server and the storage system.

netbios-ns 137/TCP ¡§C For RPC on CIFS
netbios-dgm 138 TCP ¡§C For RPC on CIFS
netbios-ssn 139/TCP ¡§C For RPC on CIFS
RSH 514/TCP(between host and filer)

DCOM incoming outgoing (DCOM assigns ports dynamically, but the following article from Microsoft describes how to restrict the range of port usage: Using Distributed COM with Firewalls.
http://msdn2.microsoft.com/en-us/library/ms809327.aspx

The following outgoing ports are generally required for any network connected Windows system:

464 - kerberos password
53 - DNS
389/TCP - LDAP
88 - Kerberos

HTTP 80
HTTPS 443

Snapdrive Webservice 808
snapdrive Webservice HTTP 4094
Snapdrive Webservice HTTPS 4095

Good luck!