I am running "cifs setup" on a new filer A, and will be using the same cifs configurations as an exisiting one B. Now, when I type "cifs domaininfo" on filer B, I am getting the list of 3 different types of DC addresses.
My questoin is which one should I pick to answer the questions that I encountered when I run "cifs setup": IPv4 address(es) of your WINS name server(s) ?
the following is the output:
NetBios Domain: abcdomain
Windows 2003 Domain Name: abcdomain.abc.com
Type: Windows 2003
Filer AD Site: xyz
Also, should I use abcdomain.abc.com to answer the question of What is the name of the Active Directory domain?
It looks like abcdomain is a child domain in the same tree as abc.com.
If that is where the filer will live, I'd use that one.
Then the resulting FQDN of your filer would be filera.abcdomain.abc.com
You should be able to leave WINS servers blank unless you really need them.
WINS (as I understand it) was/is basically windows pre-DNS name resolution. It's sort of legacy, but still in use. (Disclaimer: I'm a unix guy - this is just my understanding, I'm not selling it as hard fact!) If your existing controller has it set, I would set it on the new one. It won't hurt anything.
You can see what WINS addresses were used on the existing controller by looking in filerB:/vol/vol0/etc/cifsconfig_setup.cfg (or the appropriate root CIFS share of vol0. I would use those same addresses. Once you join to the domain, I would also set the same preferred addresses, unless you know of a reason in your environment that you shouldn't do this.
And bingen is right - use abcdomain.abc.com as the domain name.
Thank you all for your inputs.
Bill, I checked the file filerB:/vol/vol0/etc/cifsconfig_setup.cfg, there is only one line in it:
cifs setup -security unix -cp 437 -NTFSonly
Does that mean we did not specify any IP's for WINS server? if this is the case, then I should anser "n" to the question of "Do you want to make the system visible via WINS?", and without giving it any IP's?
ONTAP will always show the domain netbios name, and every domain has a netbios name.
WINS was used by, and required by, NT4 domains. You generally don't use WINS anymore as Active Directory domains don't require it and it basically is just inferior to DNS in pretty much every way possible.
When you run CIFS setup, just say "no" to WINS. Unless your environment needs it for something odd or you actually have an NT4 domain. Which I assume you don't since the old filer says "Windows 2003" for the domain type.
I am getting another issue now.
I have been prompted for root password. I have tried the root password for the filer 4 times now, and pretty sure I entered the right one. Is it possible it is not asking the root passowrd for the filers? What root password is OnTap asking,other than the filer's root password?
CIFS requires local /etc/passwd and /etc/group files and default files
will be created. The default passwd file contains entries for 'root',
'pcuser', and 'nobody'.
Enter the password for the root user :
Password validation failed. Password has been used sometime in the last 6 change
Hmm, I have not seen this, but I did find something on it. From the software setup guide:
During CIFS setup, you are prompted for the root password. When you enter the current password, it is not accepted. If you want to continue using the same password, you can enter Ctrl-C to stop the setup script and set the password history to 0. If you want to use a different root password, you can change the password at the prompt. If you modify the password history to 0 to use the existing password, you need to reset it to the old value after completing CIFS setup.
Check "option security". security.passwd.rules.history looks like it started defaulting to 6 in 8.0, and is enforced if security.passwd.rules.enable is on, which is also the default in 8.0. Try disabling the rules or setting the history to 0, then try again.
I followed what you said, and it went through! it is really a big through.
Now, I am getting the follwoing error, I believe it is due to I don't have the priviledge on AD. What does people usually do from here? Should I ask AD admin (belong to different group) to come here, and enter the name and password on the prompt, then I can continue? or are there any other ways to do it?
Password for firstname.lastname@example.org.COM:
CIFS - Logged in as email@example.com.COM.
*** The user you specified, firstname.lastname@example.org.COM, does not have
*** permission to create a machine account for this server in Active
*** Directory. To continue, you must specify a user with the appropriate
Enter the name of the Windows user :
"Should I ask AD admin (belong to different group) to come here, and enter the name and password on the prompt, then I can continue?"
Yes, that's pretty much what most people do that I talk to. Unless the AD admin will create an account for you that has the right to create machine accounts.
I don't know of any simplified way. I've migrated shares and share permissions before by using the /etc/cifsconfig_share.cfg file. I can't at the moment recall if I copied it over and started cifs, or just ran each line in the file, since they are all valid cifs command.
After you do the cifs setup on the new controller, you could try copying all the /etc/cifs* files over that don't look complete on the new controller. cifsconfig_setup.cfg, for example, should be fully configured after you run cifs setup. I'm not sure about cifssec.cfg. Also check all the cifs options ("options cifs") and make sure the new controller is the same.
There are also some cifs shares settings in the registry, if you set things like umask and forcegroup - search for options.cifsinternal in /etc/registry, and you'd need to apply those manually (or via a script).
Hope that helps
Your message is greatly helpful.
By reading your message, I am wondering what document I need to read through, in order to get understanding of these aspects of CIFS on NetApp filers, things like your said, use of /etc/cifsconfig_share.cfg, cifsconfig_setup.cfg, cifssec.cfg, /etc/registry etc...
Thanks you very much for sharing!
Unfortunately I don't know of any document that really talks about how the files are used. I got this info by poking around the filesystem and piecing stuff together through trial and error. There are plenty of guides available on the NetApp support site, but I think they are all ready focused on the front end (cifs setup, cifs shares -add, etc) and not so much on the back end.
Your message made me feel better, I am not the only one for a new CIFS guy.
You reminded me to check out /etc/cifsconfig_share.cfg, and there are a lot of lines with the format as following:
cifs access "share_name" S-1-5-11 Change
Could you please elaborate more about what S-1-5-11 is? I guess, it might be something to do with authentication group in Active Directory. Is that true? and how this S-1-5-11 is define? Since I don't have the access to AD, what am I supposed to see about this name?
I know this thread has been dragged for long...
You are right - the S-1-5-11 is an AD identifier (SID) of a user and/or group. You don't really do anything with it - it's meaningless on the NetApp side. Only AD knows what it refers to. When the controller is connected to AD, AD manages the share permissions, which is why they reference the AD SID.
This share permission had to be created when AD was connected; otherwise the SID would be meaningless. You won't be able to see what the SID refers to from the filer if it's not connected to AD; if it is, you can use wcc -s <SID> to see what it maps to - but you shouldn't really care, as the permissions should be made and managed by the AD guys.
I have hundres and hundres shares in /etc/cifsconfig_share.cfg, they all apear to be having the same SID.
Do I need to know what group/user does this SID represent? or as a storage admin, all I need to do is just to create a share, as far as permission or ownership all will be left for AD admin?
I have one share as following when I type cifs shares command. Does any one of fields (for instance, NetAppFileAdmin1) have anything to do with this SID?
admin_accntingfile$ /vol/adminaccounting Created on 8/22/2012
abcNET\NetAppFileAdmin1 / Full Control
BUILTIN\Administrators / Full Control
I know my questions are never ending..
cifs lookup appears to work better than wcc for me in translating SIDs. Also, I misspoke when I said the SIDs were only AD; the builtin filer users/groups map to SIDs as well. So my bet is that your repeating SID is the BUILTIN\Adminstrators group. But really, you don't need to know what the SIDs map to. They all have corresponding user/group names - these are what are used for specifying permissions. And the AD guys set the permissions.
need you guys help again.
To continue on my story. finally I am able to get DC admin to come to my desk, and just enter his id and password. It works. However, I am getting following message. What following options should I choose?
CIFS - Logged in as email@example.com.
The user that you specified has permission to create the filer's
machine account in many (754) containers. Please choose the method
that you want to use to specify the container that will hold this
(1) Create the filer's machine account in the "Computers" container (CN=Computers, Windows default)
(2) Choose from the entire list
(3) Choose from a subset of containers by specifying a search filter
Here is some background:
Currently, we have CIFS running on an existing pair of filers, and we want to migrate CIFS to the new pair, then eventually retire the existingone. So, we need to keep all informaiton, including DC information. So, what should I do from here, should I choose (1), enter a new object under "computers" container, or choose (2)?
I don't know what (2) is, is this something that I may choose from for the existing pair of filers? I don't know too much about DC.The DC admin is not so sure about what I am asking. So, I once again turn to you for help!
This is a basic AD question - if the DC admin is not the same as the AD admin, maybe I understand him not knowing, and you should find the AD guy to see what OU he want's the account in. If the DC and AD admin is the same person, and he doesn't know what you're asking, I'd be a bit worried.
My understanding (disclaimer: I'm a unix guy, not an AD guy) is that it doesn't really matter where the machine account goes - but there may (should) be standards where they want ALL the machine accounts, and there may be different rules/permissions around those OUs. If all else fails, they can do a lookup on the existing controllers and put the new ones there.
It matters in the sense that group policy objects can be applied at the organization unit level. Delegation can also be handled at the OU level.
I would assume that you would want the new filer to be in the same OU as the existing filer so that the same policies get applied. So, just get the AD admin to check ADUC and see where the old filer is, and specify the same OU for the new one.
Unless you want it in another OU, in which case you'll need to sit down with the AD team and hash it out.
NetApp has some Professional Services Consultants that are very good at AD design, so it may be a good idea to talk to your SE about getting one of them involved in the decision making process.
I used (1) choice :
(1) Create the filer's machine account in the "Computers" container (CN=Computers, Windows default)
then AD admin moved the new filer from "Computers" to the same container where the current filer located. Would that cause any issue, since he made change on AD side? Do I need to do anything on the filer to reflect the change?
The group policy of the exisiting filer on AD is empty. We have clikced the property on both new created and existing filer on AD, and made sure settings under "security" tab are all the same.
Also, in /etc/cifsconfig_share.cfg, there are a lot of commands similar to the following:
"cifs shares -add Marketing... "
"cifs access "Market..."
Should "Marketing" here, for instance, be fefine somewhere in AD? Could you please tell me where exactly can I find these in AD?
You shouldn't have to do anything on the filer if you move the AD account to a new OU.
The cifs access commands use builtin and AD groups and accounts in ACLs. But in your example, "Marketing" is the name of the share - the line hasn't gotten to the ACL bit yet. The share names themselves are not a part of AD. You should see something like:
cifs access "share" S-1-5-22-1241646611-414781642-847300705-202075 Read
That S string is the SID, which maps to either an AD or builtin account. cifs lookup <SID> should tell you what it maps too. As for exactly where in AD to find the group or account, it could be in any OU - your AD admin would be able to help you.
Need your help again. On one of filers here, when I run cifs setup, and enter the domain admin account and password, i got the following message, Any idea please? I am fine with previous filers.
Password for firstname.lastname@example.org:
CIFS - Logged in as email@example.com.
*** Setup cannot bind to an LDAP server for the ABCNET.ABC.COM active
*** directory domain, and so cannot continue.