Did you know?

Well I didn’t. More specifically I didn’t know that Server 2008 behaves quite differently to 2003 when it comes to choosing a source IP address on a server with multiple IP addresses on the same interface.

Previously on Server 2003 the source address would be the primary address on the interface in question. This address would also register in DNS. Server 2008 and higher uses the address which has the most bits in common with the default gateway. This is worked out in binary and I won’t bore you with the details. To make this a little bit easier on us Microsoft have released a hotfix which introduces the SkipAsSource flag. To use it you have to remove the IP addresses and re-add them using the netsh command.

For example:

netsh Int IPv4 Add Address <Interface Name> <IP Address> SkipAsSource=True

To check that the command worked as expected run:

Netsh int ipv4 show ipaddresses level=verbose

You should see something like this:


In case you can’t see the Skip as Source setting you still need the install the hotfix above.

You would hope that you’re done at this stage but there are some issues with this hotfix and you will need to install two more:


KB2554859: The “skipassource” flag of IP addresses is cleared after you use the GUI to change IP settings of a network adapter in Windows 7 or in Windows Server 2008 R2

KB2551090: IIS Manager does not display IP addresses that are assigned to the network adapter together with the skipassource flag

This does the trick and gives you control over which addresses are registered in DNS and used as source.







NPS Migration Steps

I have been involved in a small migration project over the last couple of months and will be sharing my notes. In all fairness most of this comes from Microsoft guides which are pretty good and comprehensive. What I’ll be sharing is a rather condensed version so you might want to read through the original articles before undertaking your own migrations.

First up is the network policy server migration which is very straight forward.

NPS Migration Steps



Preparing the source server:

  • Gather information for the table above.

Preparing the destination server:

  • Configure new server OU and group membership identical to the source.
  • Install NPS role service.

Exporting settings from the source server (Windows Server 2008)

  • On the source server open elevated command prompt and run:
    netsh nps export filename=”\\share\IT\NPS\file.xml” exportPSK=YES

Importing settings to the destination server:

  • On the destination server open elevated command prompt and run:
    netsh nps import filename=”\\share\IT\NPS \file.xml”

Verifying the NPS migration

Source: https://technet.microsoft.com/en-us/library/dn530780.aspx

  1. Check that NSP is running on the destination server:
    • In elevated command prompt run: sc query ias
    • In the command output, verify that RUNNING is displayed next to STATE.
  2. Verify NPS config has been migrated:
    • netsh nps show config
    • Verify that the destination server is not using default NPS settings. For example, default settings display a single policy under Connection request policy configuration with the name Use Windows authentication for all users.
  3. Verify that NPS console is displaying correct settings
    • Using the NPS console navigate to Policies, RADIUS clients and servers…etc to make sure settings are displayed as expected.
  4. Verify Authentication methods:
    In this case NSP02 uses certificate based EAP methods, the destination server might already be provisioned with a suitable certificate through autoenrollment. You might also be required to manually enroll the destination server with a computer certificate.

    • To view the certificates associated with EAP methods on CAE-WT-DC02, open the NPS console.
    • Open Policies → Network Policies → Wireless Users Services/Wireless Users General.
    • Check the Constraints tab.
    • Click Authentication Methods, and then under EAP Types click Microsoft: Protected EAP (PEAP).
    • Click Edit, verify that the correct certificate is chosen next to Certificate issued or Certificate issued to, and then click OK.
  5. Verify client connections:
    • On the destination servers In the event viewer console tree, open Custom Views\Server Roles\Network Policy and Access Services.
    • In the details pane, verify under Event ID that event number 6272 is displayed.
    • Events 6273 or 6274 indicate that client authentication attempts are unsuccessful.
    • If no events are displayed, client connection requests are unable to reach the destination server, or the server is not logging authentication attempts.


Migration file store –  you can of course export the file locally on the source server and then manually copy over.

DNS and IP addresses – Depending on how your radius clients connect to the NPS server for authentication you might want to assing the same IP addresses to the new servers, update your DNS records accordingly or update each radius client separately.

Cisco AnyConnect VPN authentication failure using NTLM

It turns out that Cisco AnyConnect VPN (through an ASA) doesn’t support NTLMv2. In server 2003 the Default Domain Controller Policy was set to Sent NTLM response only. This has changed from Server 2008 and higher which by default enforces NTLMv2 so if you want to carry on using NTLM authentication with Cisco ASA you will need to modify the Default Domain Controller Policy.

The failures you will see on the ASA and in the DC security log aren’t overly descriptive or helpful:


ERROR: Authentication Rejected: AAA failure


Logon Failure:
Reason:            Unknown user name or bad password
User Name:      username
Domain:            domain
Authentication Package:      MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

The group policy setting you want to modify is: Default Domain Controller Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level
Value: Send NTLMv2 response only. Refuse LM
Description: Client computers use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they will accept only NTLM and NTLMv2 authentication.

There are security implications with doing this but it all depends on your environment. You can find more details here: http://technet.microsoft.com/en-us/library/jj852207(v=ws.10).aspx