a blog about nothing

If you’d like a glance/overview of Win8 for ITPros, I recomend you to have a look at the “Introducing Windows 8″ preview.

Text stolen from the MCP newsletter:

“This complimentary e-book explores the great new features Windows 8 offers for IT professionals and businesses. It’s designed to help prepare you for deployment of Windows 8, deliver apps, and manage recovery, security, and virtualization”

You can download it from here: http://download.microsoft.com/download/B/1/E/B1E7F4C9-304D-456C-BD96-A2287FA7871D/Microsoft_Press_ebook_Introducing_Windows_8_PDF.pdf

If you use DirectAccess (DA), should you use a certificate on the IP-HTTPS listener from your internal CA or from a third party CA?

If you use a certificate from your internal CA, you’ll have to publish the CRL so it can be reached from the outside. If you don’t do it, external DA clients will remove the CRL from the cache after 24 hours and they will not be able to check if the certificate has been revoked or similar. DA will not work for them until they put their laptop in the internal network, and are able to reach the CRL.

The default time for the cache is 24 hours.

So I would not bother publishing the CRL, but instead use a third party certificate on the IP-HPPS listener.

If you use or consider using DA without UAG, Win8 has a lot of improvements regarding DA (features you only found in UAG).

For a complete list check out http://technet.microsoft.com/nb-no/library/hh831416.aspx

As I mentioned earlier in a post, causes of slow logons can be many things and troubleshooting this is often time consuming. I recommend you to download the ADK tools for Win8 (for the moment it’s for the Consumer preview) and use the “Windows Performance Recorder” and “Windows Performance Analyzer” to help you find the culprit.

To get an overview of the tool and some examples, take a look at this excellent TechEd session: How many coffees can you drink while Windows 7 boots?

When you use DirectAccess (DA) you have to unblock ISATAP on your DNS servers, so when clients do a DNS lookup for ISATAP they will get an answer.

If you add a new domain controller with the DNS role, you must remember to remove ISATAP from the block list. You removed it on your DNS servers when you configured DA long time ago, but will you or your successor remember to remove the blocking if you add a new DC/DNS?

I didn’t until I saw a 7600 event id on the new DC/DNS…

Too see the current settings:

dnscmd /info /globalqueryblocklist

To remove ISATAP manually from the block list:

dnscmd /config /globalqueryblocklist wpad

To avoid this from happening in the future, I configured a Group Policy (GPO) to do the job. I reckon a GPO is more reliable than a Teflon brain.

Open the Group Policy Management consol.

Create the WMI:

First you need to create a WMI filter so the GPO only apply to servers with the DNS server role. Give it a meaningful name.

Query:  SELECT id FROM Win32_ServerFeature WHERE id = "13"

(ID 13 = DNS Server)

Create the GPO/GPP:

Group Policy Objects -> New

Give it a name. I called it “GPP_Unblock_ISATAP”.

Computer Configuration – Preferences – Windows Settings – Registry

Choose New – Registry Item

Action: Update

Path: HKLM\System\CurrentControlSet\Services\DNS\Parameters

Name: GlobalQueryBlockList

Value to remove: isatap

Link the GPO to the WMI filter you created:

Link the GPO to the OU where your DNS servers reside. I linked it to the Domain Controllers OU since we don’t have any standalone DNS servers. The WMI filter will anyway only apply to DNS servers, so you can link it higher up.

You’ll have to restart the DNS server service, or reboot the server before the setting is applied to the DNS server. Check the status “dnscmd /info /globalqueryblocklist”. If ISATAP is not present you are good to go.

Notice this only apply to Win2008 and newer, since legacy OS don’t have the Win32_ServerFeature class.

If you have Win2003 DNS servers, you’ll see that the WMI filter return “false” and the GPO will not apply:

On Win2008 and newer:

Were you unable to attend at TechEd Europe 2012 in Amsterdam?

Don’t worry. You can view all the sessions on-demand at Microsoft Channel 9 for free.

TechEd: Microsoft Channel 9

Do you use Microsoft Forefront UAG 2010 to publish Lync and having problems to get it to work?

My co-worker Robert had struggeled with this for some time, but finally he managed to get Lync and mobility to work over UAG.

First we tried using the TMG part of the UAG and it worked, but I could not restart the server after the configuration. If I restarted the server the HTTP and HTTPS traffic was blocked by the default rule of the TMG. Other weirdo’s did also happened if we changed the UAG config.

We started a SR with Microsoft and they told us that using the TMG part of the UAG was not supported. It can work in some cases but if you do some configuration changes in UAG it can be broken. MS says that you should never touch the TMG settings on a UAG server.

So here is what we did on the UAG:

We added one more public IP address to the External leg of the UAG, so we have two IP addresses for Lync. One IP for lyncweb, meet and dialin. The second IP was dedicated for lyncdiscover.

We created a new HTTPS trunk for lyncweb, meet and dialin and changed the Session settings like this:

Important: The “Disable scripting for portal application” have to be ticked on the Lync trunk. This cannot be ticked on a trunk for i.e. Exchange or SharePoint. Therefor you have to create a new dedicated trunk for Lync.

We created a new http trunk for lyncdiscover and changed the Session settings like this:

Our uag console now looks like this:

The https Lync looks like this:

The http lyncdiscover looks like this:

Update:

Mobile clients will get logon servers unencrypted if you configuring the lyncdiscover on a HTTP trunk. You can skip the extra IP and configure the lyncdiscover on the Lync HTTPS trunk by doing:

Credit to Robert for getting this to work. Hope it will work for you too

For proper Kerberos authentication to take place, the Service Principal Names (SPNs) have to be registered correctly on the correct account.

SPNs are AD attributes that uniquely identifies an instance of a service for a given target host.

If you have a SQL server where the SQL service run under the Network Service or Local System account, the SPN for SQL should be registered on the machine account. If you have set the service to run under a service account (a domain user account), the SPN should be registered on the domain user.

SPNs registered on a machine account will be registered automatically, but if you use a user account you’ll have to register the SPN manually. You can use the setspn.exe tool, or use adsiedit.msc.

You can only register the unique SPN on one account. If you have duplicate SPNs in the forest, Kerberos authentication will fail.

If you have an IIS server (version 6 or prior) the Service class (http) should be registered on the application pool Identity the site is using. This is not the case if you have IIS 7/7.5. By default IIS 7 has enabled “Kernel-Mode authentication”.  The Kerberos Service ticket is then encrypted with the Machine account password no matter what account is set to run the application pool.

This weekend I attended at the NIC2012 conference in Oslo.

Many interesting sessions were on the schedule like DS MVP Brian Desmond’s “What’s new in Windows Server 8 Active Directory” and “Kerberos uncovered”.

Key notes from WinServer 8 AD:

• USN Rollback preventions when restoring a snapshot (PDCe needs to be on a Win Server 8 DC)
• Support for cloning DCs (handy when you have to deploy dozens of them)
• GUI for the AD Recycle Bin and Fine Grained Password Policy
• Dcpromo.exe is gone (you promote a DC from the server manager)
• AD delivers the mechanism for file server access with Claims Based Authentication
• A huge amount of new Powershell cmdlets

Unfortunately it looks like the video for this session is missing, though I’d recommend you to have a look at some other sessions like:

“Kerberos uncovered” by Brian Desmond:
http://vimeo.com/nicconf/review/35059113/4695c41e86

”How to Not Screw Up Your PKI Environment“ by Brian Komar:
http://vimeo.com/nicconf/review/35053082/aaff51b192

“What’s new in Windows 8 Hyper-V” by Ronald Beeklaar:
http://vimeo.com/nicconf/review/35059126/939388d621

All sessions: http://www.nic2012.com/nic2012_agenda

When a computer joins a domain, a computer account is created in AD. The computer account gets its own password that will expire after 30 days (default). When the password expire, the computer itself will initiate a password change with a DC in its domain.

When the computer starts up, it uses this password to create a secure channel (SC) with a DC. The computer will request to sign all traffic that passes the SC. If a DC says “go ahead”, all traffic that is signed passes through this channel.

Traffic like NTLM pass through authentication is typically signed traffic.

So what will happen if there is a mismatch between the computer account password? The computer tries to authenticate, but the DC says this is not the correct password.

The SC is down.

Tools like “netdom” could be used to reset the password, but this only worked to reset the SC between two DCs. It was not possible to reset the SC on a domain member. The computer had to rejoin the domain.

Syntax:

netdom resetpwd /server:<Name of a DC> /userd:domain\administrator /passwordd:admin_password

Netdom was written back in the NT4 days, and a new tool has taken over. Not just taken over for Netdom, but also for tools like Nltest. Windows PowerShell.

To reset the SC between a computer and a DC:

Open PowerShell on the computer and run the *cmdlet:

Test-ComputerSecureChannel -repair

*The cmdlet requires PowerShell 2.0, which is pre-installed on Win7/2008R2.

In Win8 there are thousands of new cmdlets, so if you have not began to look at PS. Now is a good time.

References:

PowerShell 2.0 for XP, 2003, Vista, 2008: http://support.microsoft.com/kb/968929

Symptoms of a broken SC: http://blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx

Test-ComputerSecureChannel cmdlet: http://technet.microsoft.com/en-us/library/dd367893.aspx

To access Dynamics CRM 4 (on premise) from the Internet, you’d to configure IFD and you could use i.e. ISA in a DMZ if you didn’t want the CRM server to be facing the Internet.

If you decided to use ISA you couldn’t use the built-in security provided by ISA/UAG, but you had to just tunnel all traffic through and let the CRM server authenticate the user. This was not so cool, but it was fairly easy to set up and configure.

With the release of Dynamics CRM 2011 things started to get a little more complicated. If you wanted to access CRM from the Internet you’d to configure claims-based authentication, ADFS 2.0 and IFD. UAG was not supported.

I was taken by surprise when I read about this, since Microsoft uses UAG to make i.e. Exchange and SharePoint more secure. Did they forget about CRM?

Products like Citrix Access Gateway began to take a sole lead.

Things changed with the release of UAG Service Pack 1. CRM is now supported to be published via UAG. You don’t need to set up ADFS and claims. Let the UAG do the job to secure and authenticate the users. With or without two-factor authentication like RSA.

Easy to configure, easy to understand

Reference:

Publishing: http://technet.microsoft.com/en-us/library/hh490315.aspx
UAG: http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx