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.
When you set the "altSecurityIdentities", user user1@olddomain becomes user2@newdomain on the Netapp, with all the correct ownership and security implications.
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.
/ Dejan
Added:
Found a article that describs the process. Read the last part about "Cross-realm trust"
http://searchwindowsserver.techtarget.com/feature/Kerberos-interoperability
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:jsmith@olddomain.com
Message was edited by: dejan-liuit
