cifs setup configuration

[netappmagic]

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:

filerB>cifs domaininfo

NetBios Domain:           abcdomain
Windows 2003 Domain Name: abcdomain.abc.com
Type:                     Windows 2003
Filer AD Site:            xyz

Current Connected DCs:    \\xDC02 and \\xDC01
Total DC addresses found: 20
Preferred Addresses:
                          IP1     xDC01    PDC
                          IP2                      PDC
                          IP3                      PDC
Favored Addresses:
                          IP4                     PDC
Other Addresses:
                          IP5                     PDC

                         ...                         ...

                         IP20                    PDC

Also, should I use abcdomain.abc.com to answer the question of What is the name of the Active Directory domain?

[billshaffer]

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.

Bill

[netappmagic]

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

[ChanceBingen]

You can always use the 'cifs lookup' command in Data ONTAP to see who they are.

[billshaffer]

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.

Bill

[netappmagic]

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 admin@abcnet.cit.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
        account.

(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!

[billshaffer · Accepted solution]

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.

Bill

[ChanceBingen]

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.

[netappmagic]

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?

Thank you!

[billshaffer]

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.

Bill

[netappmagic]

Hi Bill,

I got all your points. you have been very helpful!

[netappmagic]

Hi Bill,

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 dominadmin@abcnet.abc.com:

CIFS - Logged in as domainadin@abcnet.abc.com.

***     Setup cannot bind to an LDAP server for the ABCNET.ABC.COM active

***     directory domain, and so cannot continue.

[billshaffer]

Not sure - looks like the controller can't talk to any of the LDAP servers the domain gave it, or the domain didn't give it any LDAP servers?  Try "cifs domaininfo" and see what it says.

Bill

[ChanceBingen]

You might check and compare the /etc/resolv.conf and /etc/nsswitch.conf between working and non-working filers.

Time skew can also make you unable to log into a DC, so you may want to add that to the check list as well.

[netappmagic]

I made two changes and it works now:

1. change netgroup in /etc/nsswitch.conf from netgroup: files    nis  ldap to netgroup: files nis files

1.      2. options dns.update.enable on

this I don't know why these 2 changes made different though.

[netappmagic]

Bill and Bingen,

Thank you all for you help on this issue. Appreciate all your time!

[Kevinnguyen]

Hi Bill,

I hit the same problem, but can not fix it by changing ldap to file in nsswitch.conf. Is there anything else, please help....

Thanks,

Kevin.