Trying to use CNAME in a UNC path

[Greg Ercolano]

I have a windows file server with an unfortunately long filename (CG-ADMIN-FS01LAX)
assigned by 'the powers that be', and this name is finding its way into our R&D department's
UNC pathnames, eg. \\CG-ADMIN-FS01LAX\data\xxx, and we'd like to instead use a shorter name.

We've gotten the 'powers' to assign us a CNAME in DNS for the box, "CGSRV",
so that we can enable users to use the shorter CNAME oriented UNC path, \\CGSRV\data\xxx,
without breaking existing paths.

I solved the apparently common 'duplicate name exists' error with these two tweaks
on the file server:

o Add "DisableStrictNameChecking" as per <http://support.microsoft.com/default.aspx?kbid=281308>
o Add "OptionalNames" with CNAME, as per <http://support.microsoft.com/default.aspx?kbid=829885>

After rebooting, I now have what looks like an authentication problem with the CNAME path:

C:\> dir \\CG-ADMIN-FS01LAX\data\ -- regular name OK
[listing shows OK]

C:\> dir \\CGSRV\data\ -- CNAME path fails with a perm error
Logon failure: unknown user name or bad password.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These results are from a DOS window /on the file server itself/, an XP Pro 64
with a WORKGROUP config.

This has me stumped a bit.. "CGSRV" resolves to the same hostname via the CNAME,
so why would there be an authentication problem?

I opened up the ACLS on the 'data' dir to ensure EVERYONE:F and GUEST:F just to make
sure ACLs aren't tripping me up.

Any suggestions on how to solve this?

(I'm posting here to m.p.w.server.dns because I figure anyone trying to use CNAMEs
in this way have been down this path already)

[Wendel Hamilton]

You can't use CNAME or A records to rename the path to the sever because it
uses NetBIOS in the host resolution when it looks up the ACL so it won't
resolve the CNAME. Why not just map the share to a drive letter.

[Greg Ercolano]

I thought assigning the 'optional netbios names' using the 'OptionalNames'
link (in the original post) covered having multiple netbios names for a server.

Is there a better document for assigning multiple netbios names to an
XP Pro or Win2K Pro machine?

Definitely having the ability to assign multiple Netbios names for a file server
(that doesn't have DFS capabilities, such as XP Pro) is desireable, such as for
fail over scenarios, where a file server is restored to another file server.

For several reasons; just a few: we have background processes accessing the
file server via a service unaffected by logouts. We find drive letter mappings
too volatile; they can disappear or be remapped while these background processes
are running, causing them to fail in mid execution. UNCs don't have this problem.

Also, we have a mixed environment where drive letters are not an option.
The background processes are usually third party software that runs on Windows
and Mac OSX that loads its own data files that have the pathnames embedded in them.
These files must be able to run on both platforms (windows + macosx), and we find
'front slash' versions of UNC paths resolve on both platforms equally.

Our goal is to have better control of the UNC names, so we can use more generic
names appropriate to file pathnames in the paths, and not be locked to complex
hostnames.

Also, being able to use aliases for the UNC paths would help us in situations
where we need to move data from one machine to another without affecting hard
pathnames.

[Wendel Hamilton]

I believe what happens is this.
You hit the share using the \\CNAME\share of the server
It queries a DC and itself for ACLs for \\CNAME\share (which none are
resolved)
The DC and itself returns no ACLs because it knows nothing about \\CNAME in
any of the ACLs.
You are denied.
I've not heard of any way around this but that is not to say there isn’t.
It may be possible if you stop using NetBIOS over TCP/IP.
But it probably still wont work as it will still be unable to get the
computer SID which I think is stored in each ACL.

[Greg Ercolano]

Yes, I'd agree it sounds like an ACL problem where CNAME\username
is being used for authentication instead of HOSTNAME\username,
or some such.

The odd thing is that if an association is made between HOSTNAME and CNAME,
that association would be applied universally throughout the
path and authentication subsystems.

I'll try posting on one of the other Windows groups; if a solution
is found, I'll try to follow up here.

[northshade]

Microsoft has addressed the issue and the fix can be found in KB 281308

[alejandro_r]

If you have the computer name in Active Directory Users and Computers you should delete it. After do that, everything works ok.

[Lanwench [MVP - Exchange]]

Hi - just fyi, you seem to be responding to a rather old/stale post which is
no longer on the Microsoft servers. I suggest you start using a newsreader
instead of your forum interface, and you'll get all the current posts (plus
plenty of other advantages).