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:

skipassource

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.

References:

https://blogs.technet.microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/

http://blogs.technet.com/b/rmilne/archive/2012/02/08/fine-grained-control-when-registering-multiple-ips.aspx#pi63079=2

 

 

 

Windows 8.1 hangs after changing expired password at logon

Update: This is now fixed in the following updates:


 

I have spent the last few weeks looking at an issue where after a user gets prompted to change their expired password at logon Windows just hangs at either Welcome or Changing your password.

I have googled every possible permutation of the search terms to no avail. Through a lot of testing I have found that disabling the group policy that sets the  default associations configuration file seems to help  but couldn’t for the life of me understand why. So decided to throw in the towel and log a case with Microsoft support and then as it often happens this blog post crops up: http://blogs.technet.com/b/askpfeplat/archive/2016/01/11/does-your-win-8-1-2012-r2-win10-logon-hang-after-a-password-change.aspx .

It really nicely explains what is going and how to get around it. It also turns out it’s not just limited to changing expired passwords either.

In my case I had the Set a default associations configuration file group policy applied (Computer configuration\administrative templates Windows Components\File Explorer\ “Set a default associations configuration file”) with the file sitting in the sysvol share so the best workaround was to move the file to a non DFS share on a different server and updating the group policy.

Another viable option could be disabling the credential manager and clearing cached credentials.

Definitely have a ready through the article as you might be experiencing the same problem if you map your drives to DFS shares.

Here is what happens during the logon process (taken from the above article):

1. When the user logs on, the profile service tries to map network home folder to \\contoso.com\…

2. To do this, we need to have a call created in RDR, and this requires a SMB session setup to dcname.contoso.com

3. The SMB session setup requires a security blob created to authenticate with the target server, which is the DC.

4. To create the security blob, Kerberos will check saved credentials by calling DPAPI.

5. DPAPI cannot decode the saved credential because the master key is not available because the user’s password is reset on DC, so it will need to query the DC for a master key. This requires a named pipe call to \\dcname.contoso.com\IPC$\protected_storage

6. To connect to this named pipe, RDR found it is the same as previous call in#2 (same fqdn DC name \\dcname.contoso.com) so now session setup is queued…

7. The Kerberos thread will hang forever, and the profile service will hang forever until a reboot.

8. After reboot, the user still cannot logon with the same symptom. (note: a different user CAN log on).

Really pleased I can finally tick this one off my list after scratching my head for such a long time. I will be looking out for updates and hopefully a full fix from Microsoft soon.

 

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

Preparation

NPS01

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.

Notes:

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.

Checking out the Windows 10 Tech Preview

After not a lot of action on the IT front (mainly due to being on maternity leave for the last two months) I’ve signed up for the Microsoft insider program to check out for myself what the hype is all about.

Microsoft don’t recommend installing the technical preview on your primary computer as it is still very much a work in progress and potentially unreliable. There were a couple of reasons why I decided to go against the advice – firstly my laptop wasn’t running that well and I would have ended up rebuilding it pretty soon anyway but more importantly if I was to do the sensible thing and install Windows 10 on a virtual machine I would never get the motivation to actually use it.

In all honesty it doesn’t feel that different compared to Windows 8. There is a start menu which I quite like and you can customize the live tiles pretty well too. I haven’t quite got to grips with the task view yet but it might be useful for some users. My favourite feature so far is being able to use keyboard short-cuts like Ctrl+V and Ctrl+F inside command prompt. Oh and I nearly forgot to mention it is now possible to turn off/restart the pc from the start menu. On a more serious note it looks like Microsoft are really interested in getting some feedback – what they will do with the information is yet to be seen but ever the optimist I have already submitted a few suggestions via the Windows Feedback app.

Windows 10 will definitely please people that were after a more Windows 7 feel but it is not as ground breaking as Microsoft would want everyone to believe unless I am missing something and that’s what the comments are for.

To sign up for the tech preview go to: http://windows.microsoft.com/en-gb/windows/preview.

 

 

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:

ASA:

ERROR: Authentication Rejected: AAA failure

DC:

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

Outlook 2010 not accepting Office365 password

Just a quick post today. If one of your Office365 users suddently can’t login to Outlook 2010 (most often after password change) and you’re absolutely sure the password you’re using is correct, i.e. you can sign into outlook.office365.com and lync give this update a go: http://www.microsoft.com/en-us/download/confirmation.aspx?id=29361 . It’s worked a treat for me today!

Cisco IPsec VPN and Windows 8

I think I may have finally found a solution to my problems with IPsec VPN on Windows8. When I first installed Windows8 the Cisco IPsec VPN client worked fine for some time – I’m not exactly sure how but it did. Unfortunately after a few weeks while I could still connect to the VPN I couldn’t actually access anything across the tunnel. RDP, ping…nothing would get through.

I resorted to using Shrew Soft VPN client for a while which mostly worked but I found with some VPNs it just wouldn’t connect and I would have to use a Windows7 VM to connect to those. Today I have decided to revisit the whole situation and came accross this post .

I didn’t have the Cisco VPN client installed at that point so went straight onto installing Citrix DNE. But if you already have the client you might want to install it first.

1. Download and install Citrix DNE.

2. Install Cisco IPsec client.

That’s all you should need to do but I’ll report back after a few weeks just in case it mysteriously breaks again. In the meantime if anyone has a better solution I’d be really glad for it.