Actually, the default behavior is as Tim explained. It is not necessary to specify a wildcard mapping for the domains, unless you want to exclude certain domains. I'd recommend opening a case so we can get to the bottom of why this is not working as expected.
Mark
I guess I didn't explain my problem very well. Everything is working as expected. Our problem is that we are a University. We do not centrally manage our Windows domains and many folks do not belong to domains at all. Many departments have their own departmental Windows domains with their own user naming scheme, and we have no trust relationship with those domains. Most students have personal workstations, which do not belong to any domain.
When using Unix authentication for CIFS, it does not matter what domain you are in because the filer ignores the domain. So if your user name on the filer is "fred" you can just enter "fred" in the "map network drive" login dialog. It does not matter if this results in "fredpc\fred" or "artdept\fred" or anything else because the filer ignores the domain name and looks up "fred".
But when we switch to using our "eservices" Windows domain for auth, then the domain name is important. You cannot login to eservices\fred if typing "fred" results in "fredpc\fred". You have to explicitly type "eservices\fred" in the "map network drive" dialog box. This is not a software flaw. This is a user education issue. Right now only about 20% of our 30,000 CIFS users login to the eservices domain. The other 80% login other domains or no domain at all.
I was just curious if there was some way to avoid training thousands of people to enter "eservices\fred" instead of just "fred".
The usermap.cfg file is close to, but not quite, what we need. What we need is a way to map Windows ids to Windows ids, not Windows to Unix. It would help us if we could do this:
** => eservices*
but this is not what usermap.cfg is for.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support