a blog about nothing

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

We recently had a two day visit by some folks from Microsoft Norway. Good food and drinking, driving ATVs, and talking. We talked much about how MS saw the future and things like Lync, Intune, Hyper-V, Windows mobile, Win 8 and Win Server 8.

We are in the middle of a Oracle consolidation, so what is better than giving us some really cool t-shirts and say good luck?