Share via


navigating to a server alias from itself prompts for credentials - Windows Server 2008 R2

Question

Friday, August 16, 2013 1:53 PM

Hi

I have 2 virtual Windows Server 2008 R2 machines.

I use Radware technology to have NLB between those servers. so there's an alias for those servers

when I navigate to \alias from workstations everything works great.

when I navigate to \alias from the servers themselves I'm prompted to enter credentials.

doesn't matter what credentials I'm trying to enter - no luck... not sure what credentials it asks for but when I navigate to \server1 from server1 I get the shares without any problem

I tried the following registry keys with restarting the machine but they didn't affect anything:

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

DisableLoopbackCheck=1

2. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
DisableStrictNameChecking=1

I tried to access with FQDN instead of NetBIOS name with no luck

I tried add with serviceprincipalname for the server's account:
Setspn -S HOST\Alias ;  Setspn -S HOST\Alias.fqdn

again... no luck

what am I doing wrong? :(

btw the servers are almost identical. both use for the same purpose and have the IIS Role installed

please help

Tamir Levy

All replies (4)

Friday, August 16, 2013 10:40 PM âś…Answered | 2 votes

Not able to connect to itself on the aliax is default behavior because you are currently logged on and it looks at it as a spoof, so no matter what you enter, you won't authenticate.

I don't usually see this come up in forum posts because we try to stay away from aliasing server names in AD. However, since apparently the device you are using requires it, (I've used Kemp LBs, and they don't require it), you have to set another reg value to make it work to itself.

To fix it, look for the section below in my notes about the BackConnectionHostNames reg key you have to create. Note, as a reference back to the author, this was posted in the old Microsoft Newsgroups by a "Michael" in 2009.

===============================================

How to Configure Windows Machine to Allow File Sharing with DNS Alias

Posted by Michael
June 10, 2009
microsoft.public.windows.server.networking newsgroup

I haven't seen one article that brings together all the settings one
would need to do to make this work properly on Windows, so I thought I
would post it here.

To facilitate failover schemes, a common technique is to use DNS CNAME
records (DNS Aliases) for different machine roles. Then instead of
changing the Windows computername of the actual machine name, one can
switch a DNS record to point to a new host.

This can work on Microsoft Windows machines, but to make it work with
file sharing the following configuration steps need to be taken.

== Outline ==

   1. The Problem
   2. The Solution
          * Allowing other machines to use filesharing via the DNS
Alias (DisableStrictNameChecking)
          * Allowing server machine to use filesharing with itself via
the DNS Alias (BackConnectionHostNames)
          * Providing browse capabilities for multiple NetBIOS names
(OptionalNames)
          * Register the Kerberos service principal names (SPNs) for
other Windows functions like Printing (setspn)
   3. References

== The Problem ==

On Windows machines, file sharing can work via the computer name, with
or without full qualification, or by the IP Address. By default,
however, filesharing will not work with arbitrary DNS aliases. To
enable filesharing and other Windows services to work with DNS
aliases, you must make registry changes as detailed below and reboot
the machine.

== The Solution ==

=== Allowing other machines to use filesharing via the DNS Alias
(DisableStrictNameChecking) ===

This change alone will allow other machines on the network to connect
to the machine using any arbitrary hostname. (However this change will
not allow a machine to connect to itself via a hostname, see
BackConnectionHostNames below).

    * Edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\lanmanserver\parameters and add a value
DisableStrictNameChecking of type DWORD set to 1.

=== Allowing server machine to use filesharing with itself via the DNS
Alias (BackConnectionHostNames) ===

This change is necessary for a DNS alias to work with filesharing from
a machine to find itself. This creates the Local Security Authority
host names that can be referenced in an NTLM authentication request.

To do this, follow these steps for all the nodes on the client
computer:

   1. To the registry subkey HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\Lsa\MSV1_0, add new Multi-String Value
BackConnectionHostNames
   2. In the Value data box, type the CNAME or the DNS alias, that is
used for the local shares on the computer, and then click OK.
          * Note: Type each host name on a separate line.

=== Providing browse capabilities for multiple NetBIOS names
(OptionalNames) ===

Allows ability to see the network alias in the network browse list.

   1. Edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\lanmanserver\parameters and add a value OptionalNames of
type Multi-String
   2. Add in a newline delimited list of names that should be
registered under the NetBIOS browse entries
          * Names should match NetBIOS conventions (i.e. not FQDN,
just hostname)

=== Register the Kerberos service principal names (SPNs) for other
Windows functions like Printing (setspn) ===

NOTE: Should not need to do this for basic functions to work,
documented here for completeness. We had one situation in which the
DNS alias was not working because there was an old SPN record
interfering, so if other steps aren't working check if there are any
stray SPN records.

You must register the Kerberos service principal names (SPNs), the
host name, and the fully-qualified domain name (FQDN) for all the new
DNS alias (CNAME) records. If you do not do this, a Kerberos ticket
request for a DNS alias (CNAME) record may fail and return the error
code KDC_ERR_S_SPRINCIPAL_UNKNOWN.

To view the Kerberos SPNs for the new DNS alias records, use the
Setspn command-line tool (setspn.exe). The Setspn tool is included in
Windows Server 2003 Support Tools. You can install Windows Server 2003
Support Tools from the Support\Tools folder of the Windows Server 2003
startup disk.

How to use the tool to list all records for a computername:

setspn -L computername

To register the SPN for the DNS alias (CNAME) records, use the Setspn
tool with the following syntax:

setspn -A host/your_ALIAS_name computername
setspn -A host/your_ALIAS_name.company.com computername

=== References ===

All the Microsoft references work via:

   1. Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name           * Covers the basics of making file sharing work properly with DNS alias records from other computers to the server computer.           * http://support.microsoft.com/kb/281308    2. Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"           * Covers how to make the DNS alias work with file sharing from the file server itself.           * http://support.microsoft.com/kb/926642    3. How to consolidate print servers by using DNS alias (CNAME) records in Windows Server 2003 and in Windows 2000 Server           * Covers more complex scenarios in which records in Active Directory may need to be updated for certain services to work properly and for browsing for such services to work properly, how to register the Kerberos service principal names (SPNs).           * http://support.microsoft.com/kb/870911    4. Distributed File System update to support consolidation roots in Windows Server 2003           * Covers even more complex scenarios with DFS (discusses OptionalNames).           * http://support.microsoft.com/kb/829885

Ace Fekay
MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

This post is provided AS-IS with no warranties or guarantees and confers no rights.


Monday, August 19, 2013 11:07 AM

Hi Ace. thank you very much for the answer

I wanna ask you something and tell me if it makes sence for you

Before:
I was always able to connect to \alias from server1. even though I didn't modify nothing from the above

I wasn't able to connect to \alias from server2

from other clients I was always able to connect to \alias and access server1 or server2

**After:
**I did the all the steps above on server2 and after a restart I was able to connect from server2 to itself via \alias.

but then I noticed something super weird! no one can connect to \alias while the NLB point to server1 :o. including from the server itself.

I did the same steps + registry on server1 as well but nothing has changed. clients can connect only to server2 if the NLB navigates them to server1 they prompted for credentials

I removed all the modifications from both of the servers and the results are the same :(

doesn't sound like a normal behaviour

any ideas?

Tamir Levy


Monday, August 19, 2013 3:16 PM

Tamir,

I think it has something to do with the load balancer. I know the Kemp balancers, and I assume all others, have an option to preserve the session cookie or session status and handle it independently of when a client connects to a server in the farm, otherwise the server handles the session, so if the balancer moves the session to another server, the session is not honored because it came from some other server. I don't know if I'm explaining it correctly, but my best suggestion at this time is to contact the load balancer's vendor support for suggestions.

Ace Fekay
MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

This post is provided AS-IS with no warranties or guarantees and confers no rights.


Tuesday, August 20, 2013 5:51 AM

Hi Ace and thank you again for your quick answer

turns out it was my mistake!

I registered the HOSTS SPNs with -S and not with -A

I started with server2 and then I did the same on server1 and I didn't notice that -S check for duplicates

so the registration for server2 failed.

I did it again with -A and everything worked fine!

thanks

Tamir Levy