Hi all,
I'm a Unix/NFS guy, but I've been asked to allow CIFS access from a Windows box to a volume currently mounted by NFS to a Solaris box. Not a problem, I'll just use our existing CIFS setup and setup a share for that volume.
The problems are in terms of authentication. I'd like to restrict the CIFS share for /vol/appvol to JUST this single windows host (winbox) and user (appuser).
But the user "appuser" is a purely local account on both the Windows and Unix systems. They're the same name luckily, but neither is on the NIS or AD domains.
So I've setup the usermap.cfg on the Netapp (3140, OnTap 7.3.1.1) to look like this:
winbox#appuser <= appuser
But I've also tried:
winbox\appuser == appuser *\appuser == appuser *\appuser => appuser
And I've setup the share with:
rsh filer cifs share access appvol appuser Full Control
but without any luck. It still asks for a password, but then refuses to let me in. Note that the filer doesn't really have a concept of this username, since it's purely local to the Unix and Window hosts. Do I need to add this username into NIS and/or AD to make things work?
So I decided to try first by adding the 'appuser' account into my NIS domain, with a matching password to the host local Windows account. No luck so far. Looking at things using 'wcc -u appuser' on the filer, I get "Mapped user not found" even though I can now see that userin NIS on other unix clients.
The funky thing is that I can see with 'cifs sessions' that there is a CIFS connection from the Windows box to the filer, but it says:
x.y.z.2(WINBOX) is connected, but has no users.
so something is working, but not the authentication. I see in the messages file on the netapp the following:
Fri Sep 10 10:34:01 EDT [auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user appuser of domain WINBOX from client machine x.y.z.2 (WINBOX). Fri Sep 10 10:34:01 EDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: Trace DC- attempting authentication with domain controller \MARL-DC. Fri Sep 10 10:34:01 EDT [auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000064: D C indicates user is not from a trusted domain. Fri Sep 10 10:34:01 EDT [auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: login from x.y.z.2 rejected because guest account not set. Fri Sep 10 10:34:01 EDT [auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: Delaying the response by 5 seconds due to continuous failed login attempts by us er appuser of domain WINBOX from client machine x.y.z.2.
So maybe I need to add in a guest user? But I don't want a general guest user at all, I really want a very limited share setup for just two hosts and one username.
Any hints appreciated.
Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087
Any hints appreciated.
Hi John, If you want to configure local user accounts on the filer for your cifs users, when you run 'cifs setup' make sure you choose option 3, "Windows Workgroup Authentication". Then you can create a user account on the filer for that cifs user.
useradmin group add cifsonly -c "This group is for non-admin CIFS access" -r none useradmin user add appuser -c "Non-administrative CIFS-only user" -g cifsonly
Now, because of the way that the filers map windows id's to unix id's you still need to create an entry in the filers /etc/passwd file for the user you just created. Give it a unique uid and gid that are higher than the uid's and gid's that are currently in the /etc/passwd file and just give it a '/' as the home directory.
Example:
root:_K9..qPPDSr/2SCvwCSTSc:0:1::/: pcuser::65534:65534::/: nobody::65535:65535::/: appuser::65536:65536::/:
In my case, due to permissions issues, I needed to map my cifs user to root to get around a permission's issue. You probably don't need it but here is the syntax I used to do so.
*\appuser => root
Now you should be able to create a share, assign the appuser privs to it and they should be able to get in. If not you can turn on cifs login tracing like so:
options cifs.trace_login on
Good luck!
-- Romeo Theriault System Administrator Information Technology Services