2010-12-22 10:43 AM
I need to access our NetApp via CIFS from 2 different domains while we migrate all useres/computers from one domain to the other. We have thought of changing the netapp to work with internal local users or users in /etc/passwd so users can access to it previous local authentication. However I am getting access denied without even challenge to credentials. Do you know if that is possible? It works ok if we use domain authentication but obviously only for done domain, not 2 at the same time.
Any way to do that? Since it is temporary we don't mind having to challenge the user for user and password and check it against local filer users.
Thanks in advance.
2010-12-22 10:58 AM
With Multistore you could create a vfiler and join it into the second domain.
I hope this response has been helpful to you.
At your service,
(P.S. I appreciate points for helpful or correct answers.)
2010-12-22 11:13 AM
Well we want just a temporary solution access. It is not like it worths to purchase new products for just this step. Is it technically imposible with a normal NetApp filer?
2010-12-22 12:16 PM
It is possible to connect to netapp filer from another domain using trusted domains, without doing another login (not that you see anyway, everything is automatic)
It works by setting "altSecurityIdenties" attribute for each user in the "netapp" (receiving) AD domain.
That way you get a one-to-one user mapping (or many-to-one whatever you need is) for accessing the Filer.
We successfully experimented with this, but at the end it failed on the fact it didn't work as we expected/wanted in NFS envirovment.
If you use ony CIFS then this might be the answer you are looking for.
It works by a way of Microsoft utilities the Kerberos protocol in a ingenious way with a extension called PAC.
Simply put it the Kerberos secret is usualy some random data passed between the client and server.
Windows (and obviously Netapp) instead throws in data about the account, like SSID/username and/or other stuff.
As the client doesn't interpret this data, its just recrypting and passing it on again, it even works (although limited) with non-Windows clients.
But as it need to pass on more bytes than a "standard" Kerberos ticket some implementations might fail.
Hope this helps.
Found a article that describs the process. Read the last part about "Cross-realm trust"
The altSecurityIdentities value has to be prepended with the keyword "Kerberos:"
ie a LDAP attribute definition in the receiving AD could look like this.
dn: cn=John Smith,cn=users,o=newdomain,c=us objectclass: inetorgperson cn: John Smith sn: Smith altsecurityidentities: Kerberos:email@example.com
Message was edited by: dejan-liuit
2010-12-23 02:53 AM
Thanks for your answer, it helps but there is still some peculiarities in our environment. Do you know if there is just a simpler way to connect? I just want to have access from any windows machine using the local user and password users in /etc/passwd I dont mind being challenged.
2010-12-23 02:58 AM
That's easily achieved if that's all you want.
Simply create a local user on the filer (use the MMC to connect to the NetApp if this is easier for you), and then when you try to connect to a CIFS share or map a drive, use this local user to authenticate. The filer (even when in a domain) fully supports local users, exactly the same as a windows machine would do.
I was actually working with a customer on this last week. The following KB article may be of assistance to you: https://kb.netapp.com/support/index?page=content&id=2010383
2010-12-23 03:49 AM
I just get this:
The account is not authorized to log in from this station.
If I try with an non existing user then i get (which makes perfect sense):
Login failure: unkown user name or bad password.
Any idea? it works great if joined into the domain.
2010-12-23 04:08 AM
Yes, they are users in /etc/passwd
The CIFS share is everyone FullAccess
The clocks are quite synced like 3-4 seconds of diference.
I am trying both /etc/passwd and windows workgroup configs. None of them seems to work. Not sure what I can be doing wrong. User to be authenticated because if I try wrong password or user I get the other error...
2010-12-23 04:15 AM
It could be an issue with SMB signing: http://support.microsoft.com/?id=281648 Also check the CIFS options on the filer (from the CLI run "options cifs" and check the smb signing options).
From this same host, can you connect to a share on the filer using a different user? Say a domain user or local admin on the filer?