Network and Storage Protocols

Access NetApp from several Domain (via CIFS)

cr_emilio
26,486 Views

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.

34 REPLIES 34

ekashpureff
24,320 Views

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
ekashp@kashpureff.org
NetApp Instructor and Independent Consultant
http://www.linkedin.com/in/eugenekashpureff

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

cr_emilio
24,320 Views

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?

dejanliuit
24,689 Views

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

cr_emilio
24,689 Views

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.

chriskranz
24,689 Views

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

cr_emilio
24,689 Views

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.

chriskranz
24,689 Views

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?

cr_emilio
24,689 Views

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

chriskranz
24,689 Views

Same timezone?

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?

cr_emilio
10,598 Views

Seems like no signature

cifs.LMCompatibilityLevel    1
cifs.audit.account_mgmt_

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.allowed_users
cifs.audit.liveview.enable   off
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.nfs.enable        off
cifs.audit.nfs.filter.filename
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.guest_account
cifs.home_dir_namestyle
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.perfmon.allowed_users
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.scopeid
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
cifs.wins_servers
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

chriskranz
10,598 Views

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?

cr_emilio
10,599 Views

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

chriskranz
10,599 Views

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.

cr_emilio
10,230 Views

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

chriskranz
9,335 Views

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

cr_emilio
9,335 Views

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

chriskranz
8,139 Views

... and then setting the password manually?

cr_emilio
8,139 Views

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

chriskranz
8,139 Views

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.

ekashpureff
8,139 Views

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
root:_J9...crlrN3mwj5GjQs:0:1::/:
ekashp:_J9..xJx4OWqsuoJFXps:1001:1001::/:
pcuser::65534:65534::/:
nobody::65535:65535::/:
ftp::65533:65533:FTP Anonymous:/home/ftp:
sim1> useradmin user list
Name: root
Info: Default system administrator.
Rid: 0
Groups:

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
ekashp@kashpureff.org
NetApp Instructor and Independent Consultant
http://www.linkedin.com/in/eugenekashpureff

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

Public