Network Storage Protocols Discussions

Access NetApp from several Domain (via CIFS)


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.



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,

Eugene E. Kashpureff
NetApp Instructor and Independent Consultant

(P.S. I appreciate points for helpful or correct answers.)


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?


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


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

Message was edited by: dejan-liuit


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.


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:


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.


You're using a local user from the NetApp? The share is exported with everyone full control? Is the time synchronised properly between the 2?


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...


Same timezone?

It could be an issue with SMB signing: 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?


Seems like no signature

cifs.LMCompatibilityLevel    1

events.enable on
cifs.audit.autosave.file.extension timestamp
cifs.audit.autosave.file.limit 0
cifs.audit.autosave.onsize.enable off
cifs.audit.autosave.onsize.threshold 90%
cifs.audit.autosave.ontime.enable on
cifs.audit.autosave.ontime.interval 1d
cifs.audit.enable            on
cifs.audit.file_access_events.enable on
cifs.audit.liveview.enable   off
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.nfs.enable        off
cifs.audit.saveas            /etc/log/adtlog.evt
cifs.bypass_traverse_checking off
cifs.client.dup-detection    ip-address
cifs.comment                 P839 NetApp Simulator
cifs.enable_share_browsing   on
cifs.gpo.enable              off
cifs.gpo.trace.enable        off
cifs.grant_implicit_exe_perms off
cifs.home_dirs_public_for_admin off
cifs.idle_timeout            1800
cifs.ipv6.enable             off
cifs.max_mpx                 50
cifs.ms_snapshot_mode        off
cifs.netbios_aliases         P839NETAPP
cifs.netbios_over_tcp.enable on
cifs.nfs_root_ignore_acl     on
cifs.oplocks.enable          on
cifs.oplocks.opendelta       8
cifs.per_client_stats.enable on
cifs.perm_check_ro_del_ok    on
cifs.perm_check_use_gid      on
cifs.preserve_unix_security  on
cifs.restrict_anonymous      2
cifs.restrict_anonymous.enable on
cifs.save_case               on
cifs.search_domains          MYDOMAINNAME
cifs.show_dotfiles           off
cifs.show_snapshot           off
cifs.shutdown_msg_level      1
cifs.sidcache.enable         on
cifs.sidcache.lifetime       1200
cifs.signing.enable          off
cifs.smb2.client.enable      off
cifs.smb2.durable_handle.enable on
cifs.smb2.durable_handle.timeout 16m
cifs.smb2.enable             off
cifs.smb2.signing.required   off
cifs.snapshot_file_folding.enable off
cifs.symlinks.cycleguard     on
cifs.symlinks.enable         on
cifs.trace_dc_connection     off
cifs.trace_login             off
cifs.universal_nested_groups.enable off
cifs.weekly_W2K_password_change off
cifs.widelink.ttl            12h
Yeah they are in the same timezone. I cannot connect to any share in the filer I can only can if I join the netapp back to the domain


And when you authenticate to the share, you use "filername\username" and not just "username"?

Not entirely sure in that case. I've run filers in workgroup mode on many occasions without issue. Silly questions, but CIFS is definitely running? You ran through CIFS setup and configured it in workgroup mode?


Thanks for your time Chris.

Yes actually I have tried all the different combinations I think...

With workgroup stuff:

net use x: \\hostname\share /user:username ---> I get account is not authorized

net use x: \\hostname\share /user:hostname\username ---> I get bad user

With /etc/passwd:

net use x: \\hostname\share /user:username ---> I get account is not authorized

net use x: \\hostname\share /user:hostname\username ---> I get account is not authorized

Actually it doesnt matter if I use an account which exists or not I always get the same error with /etc/passwd...


Based on the fact that "hostname\username ---> I get bad user", can you confirm how you are adding the user locally onto the NetApp please? You definitely want to get this working in workgroup mode and not using /etc/passwd.


Actually I am adding the users in /etc/passwd. My idea is, for legacy reasons, to use Unix permissions and try to auth against /etc/passwd. This worked in our previous environment but authenticating against AD. Just want to make it work outside of the domain for several weeks...


You're using "useradmin user add" to add new users then? Not editing /etc/passwd directly?


I am using users in /etc/passwd not adding users from CLI.


... and then setting the password manually?


Mh how should I set the password? Isn't it the hash in the /etc/passwd file?


No, it uses a shadow file to store the password I believe.

You set the password in the normal UNIX way, on the CLI type passwd and enter the user you want to change it for.

I'd highly recommend not editing the /etc/passwd file manually however and use "useradmin" instead. It does all the steps for you.


Chris -

Some clarification is needed here, I think.

Authentication can be confusing in modern Data ONTAP.

As far as I know ...

There are two different sets of local users kept in Data ONTAP:

RBAC users kept in the registry and managed with the 'useradmin' command.

These are the users used for Workgroup type authentication. Passwords can be

managed with the 'passwd' command

/etc/passwd users. There is no shadow file - passwords are kept in /etc/passwd.

/etc/passwd will be used for multiprotocol user mapping and for cifs authentication

in a non-windows workgroup ( /etc/passwd ) cifs setup and FTP.

These users are managed by editing the file. You generate a password hash for an /etc/password user with the 'cifs passwd' command, then paste it into the file.

Here are some examples to illustrate:

sim1> rdfile /etc/passwd
ftp::65533:65533:FTP Anonymous:/home/ftp:
sim1> useradmin user list
Name: root
Info: Default system administrator.
Rid: 0

Name: administrator                  
Info: Built-in account for administering the filer
Rid: 500
Groups: Administrators

sim1> cifs passwd mynewpasswd
password is _J9..VLG2fYad1gOEuKc

root exists in both sets of users.

administrator only exists in RBAC

ekashp only exists in /etc/passwd

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff
NetApp Instructor and Independent Consultant

(P.S. I appreciate points for helpful or correct answers.)

NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner