I believe the usermap.cfg is your ticket. But only if I am understanding your issue correctly.
If your usernames are unique, i.e. only 1 fred will ever open a CIFS session on a particular filer, then you should be able to do something like this in the file with great success;
<DOMAIN>* == * <DOMAIN2>* == * <DOMAIN3>* == * Etc. etc.
Essentially, ESERVICES\FRED will map to unix fred, but so will DONKEYDOMAIN\FRED. So your problem will be duplicate ID's.
The == specifies a two-way mapping, i.e. unix fred will also map to the first domain that is found in the list that has a "fred/FRED". If you omit the ==, it will be implied by default. i.e. <DOMAIN>* == * is the same as saying <DOMAIN>* *. If youi want the mappings one way, use => or <= .
The usermap.cfg parses from top to bottom, so the first match will be the mapping that is used. I do not know if there is a limit to the number of entries. If you need to enter many hundreds of domains, this may become an issue and you may see some slow authentication. For more details on this you will need to talk to a NetApp engineer.
There may also be a way to do it thus;
** == * And combining the cifs.search_domains option to specify the order that the domains are searched. If you omit this setting, they are randomnly searched. So, it may be wise to place your highest populated domains at the top of the list to speed up authentication. Once the mapping cached by the filer, things should move through a lot faster.
Even if you have duplicates, my guess is that there will not be many. Particularly if you have good practices regarding the creation of user accounts. If there are, you simply disrupt a "few" users by modifying their user names and associated data. If this is 10% of your 30,000 users it will still be a lot of work, but a lot less than the full 30,000 coming down on you.
Test it out, let me know how it goes. Good luck!
Thanks, Aaron
-----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Wednesday, 2 February 2005 3:16 AM To: Kazsuk, Tim Cc: toasters@mathworks.com Subject: Re: Switching from NIS auth to Windows Domain
If the user names are the same on the Windows side and the Unix side, regardless of what Domain those users are a part of, you shouldn't have any issues with the drive mappings. As defined in the "System Administration - File Access Management Guide for Data ONTAP 6.5" pg.93, these are the steps taken when a CIFS session is requested:
- It searches the /etc/usermap.cfg to see whether an entry matches the
user's Windows domain name and user name.
- If an entry is found, Data ONTAP uses the UNIX name specified in the
entry to look up the UID and GID from the UNIX password database. If the UNIX name is a null string, Data ONTAP denies access to the CIFS user.
- If an entry is not found, Data ONTAP converts the Windows name to
lowercase and considers the UNIX name to be the same as the Windows name. Data ONTAP uses this UNIX name to look up the UID and GID from the UNIX password database.
If that doesn't work, you also might want to look into setting up the usermap.cfg file in such a way that will work in your environment.
Regards,
Thanks, but that's not the problem. Right now when you "map network drive" and you fill in the username field in the dialog box, you do not need to specify a domain name. If you enter "fred" in the dialog box then your PC supplies a domain name for you automatically. Because we are using Unix style login for CIFS, the filer strips off the domain name and looks up your account using just "fred".
However, once we switch to Windows domain auth, if you enter just "fred" in the username field, and if your PC supplies something other than "eservices" for the domain name (very likely here) then your username is incorrect and you cannot login. You don't even get to the point where your Windows domain credentials are mapped to your Unix UID, etc.
Our user education problem is teaching 30,000 people who currently enter just "fred" to start entering "eservices\fred" instead. I was hoping that there might be a magic option on the filer that would help us avoid this.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ***************************************************************