Crack a 2048 bit certificate

I have no background in determining how accurate this claim is, but the video is interesting, and even if it is only 1% accurate (in terms of time needed), then I think we are good.

Crack a 2048 bit certificate

YMMV

IIS AAR hotfix

With TMG on the verge of no longer being sold, we need to find some reasonable alternatives to Reverse Proxy solutions for both Exchange and Lync.

IIS Application Request Routing is one such solution that may work for you or your client’s environment. If that is the case, then you will want to be aware of this hotfix: MS KB 2785586

http://www.microsoft.com/en-us/download/details.aspx?id=35827&WT.mc_id=rss_alldownloads_all

YMMV.

Private Domain Certificates

Today, you can get a public Certificate Authority  - DigiCert, Entrust, etc – to issue you a trusted certificate for your internal domain.  For instance, if you have an internal AD name such as domain.local, or domain.tld, or any other that is not registered according to the governing body, then your certificate provider will issue you a certificate for the FQDN of your internal servers and your devices will trust that certificate providing your devices trust the issuer – standard fare for most of the public CA issuers.

In an effort to tighten security on the Internet by creating more stringent standards, the CA/Browser Forum recently formulated new guidelines in their Baseline Requirements for issuing SSL certificates.

One of the new changes is the elimination of certificates using internal names. This change makes it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as being owned by the organization that is requesting the certificate.  According to this CA/Browser  document:

Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

In addition, it appears that internal name certificates will NOT be issued after 1 Nov 2015.  Or, at least DigiCert will not issue them after that date:

In accordance with this new standard, DigiCert will no longer issue certificates to these internal names with expiration dates after November 1, 2015.

If you fall into this category, you should begin planning now to: a) deploy internal PKI and figure out how that action will change your environment(s); or b) change your internal AD DS name (yuk!).

Interesting note:  www.digicert.com is already planning ahead to help you out!  See this nifty tool.

YMMV

Exchange 2010 CAS OWA Re-direct

Situation

A client asked me to simplify the OWA URL so that the users (who apparently cannot learn new methods or change their shortcut) would not have to actually type HTTPS or /owa but instead just be able to blindly enter mail.company.com and have it work.  Pretty easy, eh?  Not so, as it turns out.

Yes, I know all about how to “Simplify the Outlook Web App URL”  - I also needed to create a deny and redirect on the TMG layer to cover those users who were outside the firewall.  For the TMG layer I follow fellow MVP Richard Hicks blog article.  Tastes great and is less filling.  For the CAS layer, I follow the Brian Desmond article.  Also tastes great and is equally less filling.

With all that expert help behind me, you’d think I was done early that night, eh?  Not.

What Happened

Normally,  I just step through the well-documented process from the CHM/online help, and  double check myself with the Desmond blog, and es finite!  Not this time.  As it turns out (as the stomach churns) the web.config in the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa folder (your install dir may be different) was not updating properly.  Odd.  No matter what I did, the /exchange, /public/ and /ExchWeb vdir’s would not stay redirected as needed, and the /owa vdir kept getting a redirect also – which results in a redirect loop – and this is not good.

I noticed that the web.config file (previously mentioned above) did not have the expected lines… what I had was this:

Nothing!

I went around this several times.

The Fix I Used

I toggled the /owa to this:

Which, after an iisreset /restart gave me this in the web.config file:

<system.webServer>
    <httpRedirect enabled="false" />
</system.webServer>

Based on this forum article, I was expecting to see this:

<system.webServer>
  <httpRedirect enabled="true" destination="/owa" exactDestination="false" childOnly="false" httpResponseStatus="Found">
  </httpRedirect>
</system.webServer>

Well, says I, it ain’t right.  So, I did a little cut n paste and inserted that into my web.config file.  Then did an iisreset /restart again.

As expected, the /OWA vdir was marked to redirect:

As were the /exchange, /exchweb, and /public (as they are needed that way).

Hmmm.  OK, if manual methods are needed, I am all for it.  I went back to the web.config file and removed those lines I just put in there… and did another iisreset /restart.  and voila!

Why I had to jump through the hoops like this I do not know, but these screen shots are from my lab, which is identical in build to the client (gotta love those labs) and I reproduced it step for step.

FWIW, Pat Richards has a script on his blog that would appear to fix this also.  Also, remember that when you do this, the OAB is going to broken and to fix that you need to add the “authenticated users” group to the /oab/webconfig file as shown here.

YMMV.

Create CSR from TMG

Scenario

You need to create a Certificate Signing Request (CSR) for your TMG to support Lync (or Exchange or whatever) - AND you need this certificate to have SAN (Subject Alternative Name) entries.

What to do?

Chad McGreanor has a great write-up on this!

Changes?

If you do not already have a Local Computer Certificates\Personal\Certificates container in your TMG deployment, you can still use this process – by accessing the CSR process as shown here:

YMMV

2008r2 and TMG and VPN = NO!

The Issue

Having just ran around the world on this, it would appear that even with TMG SP1, Server 2008R2 does not allow TMG to do simple PPTP VPN. I foolishly thought I would insert the VPN service into my lab as a quick test.  All my web publishing rules continued to work flawlessly; Lync Web Components; NAT for my Lync, Exchange 2010 publishing – everything worked except VPN.

If you are intensely interested, the VPN connection would be made, but no traffic was allowed to flow.  Don’t know why, and at this point I don’t much care. 

The Fix

I fixed it by building a new server on 2008 SP2.   If you are doing a project that includes TMG and want to have the same TMG provide VPN, you should most likely think about it and lab it before you continue.

Hopefully, someone can point out the errors of my ways and show me what I did wrong.  YMMV.

Open Services applet in Standard Mode

Ever since somebody at Microsoft decided we needed the services.msc applet to open in “extended” mode, I have been clicking on “standard” to get the view I wanted.  This last week I finally got fed up with this, and decided to do something about it.  As it turns out, this is not the easiest thing to change.  Apparently, us poor users are not allowed to change the behavior for the named services.msc.  We are not worthy. 

What you have to do is author a new named instance – and of course remember to use that one.  I was unsuccessful at renaming, deleting, or otherwise removing the original services.msc.  I am sure there is some method to do so, but I was unwilling to dink too much with an operating system that was working before I messed with it.  YMMV.

Here is what I did: (the example is using an x64 Win7 O/S, but it works equally well for Server 2008, and I imagine, Vista (why are you using that?).

Go to c:\windows\system32 and locate the services.msc applet.  Right-click it and select “author.”

When services opens, click File | Options as shown.

Now, change that console mode to “author.”

Say OK to this…

Change the view to standard…

Now, save this to a name and location of your choosing…

Now when you go to a command line (or in my case about 90% of the time a powershell prompt), and type in jmwservices.msc, I get this “new and de-proved” services applet in standard mode.  I suppose you could mod the original references to the new applet if you want to get fancy.

Enjoy!

single cert for ocs/exchange

this is a rewrite of previous post that got thrown away somehow…

Single certificate for OCS/Exchange firewall usage

Certificates can be complicated to understand, difficult to manage, and if you don’t have an internal PKI structure, downright expensive as you move forward with more and more dynamic applications that extend your Unified Communications to your remote users and business partners.

Internal certificates work wonders for your Active Directory Domain Services members. For Unified Communications, where OCS and Exchange are going to be using the same ISA 2006 server as the firewall, utilizing a Subject Alternative Name (SAN) certificate for your edge configuration and your ISA configuration can save you time, management hassles, and possibly provide cost savings as well. For internal servers, an internal PKI is just fine, but for the public interface of your system, you should most likely be looking at using a public-sourced key such as Go-Daddy, Thawte, DigiCert, etc. OCS Federation, remote users, and Public Instant Messaging Connectivity (PIC) demand public certificates. I know that I do not want to ship my internal CA root certificate to a slew of administrators and expect them to get that certificate into the correct spot for our systems to co-exist. But I digress.

The following table shows the SAN names needed on a certificate to support the base OCS and Exchange functions on ISA 2006/TMG/UAG – and I imagine that this certificate construction will work just fine on many other firewalls as well. The table comes from my test domain; you should replace my test domain with your own domain name.

Obtain a public SAN (UCC) certificate from your favorite provider; import the certificate into your OCS Edge server and your ISA server computer account Trusted Root Certificate store and then you can use one certificate for all these uses. This approach leaves you with only the one certificate to manage and renew, or, if life treats you badly, move to a new server.

 

	SAN Name (what URL?)	Usage	Notes
1	SIP.tsoorad.net	OCS Edge Server	IM, Presence, Federation, PIC
2	LM.tsoorad.net	OCS Edge Server	Web Conferencing
3	AV.tsoorad.net	OCS Edge Server	A/V
4	OCS.tsoorad.net	ISA Reverse Proxy	Web Components
5	CWA.tsoorad.net	ISA Web Listener	Communicator Web Access
6	DOWNLOAD.CWA.tsoorad.net	ISA Web Listener	Cname for CWA desktop sharing
7	AS.CWA.tsoorad.net	ISA Web Listener	Cname for CWA desktop sharing
8	MAIL.tsoorad.net	ISA publisher	Outlook Anywhere, EAS, OWA, POP, IMAP
9	AUTODISCOVER.tsoorad.net	ISA Web Listener	Autodiscover is used by outlook and OCS.

DCOM error 10009 and certificate requests

I spent the entire day learning and relearning things about ISA, TMG, and Windows Firewall.  This took me way more time than I wanted which highlights the three basic troubleshooting starting points.  I chose the wrong starting point, and then I chose the next starting point wrongly also.  Of the three choices, of course it was the last choice (midpoint and work towards one end) that proved to be the winner.  Turns out that TMG/ISA/WF all had a part in this.  WF was the culprit on the CA, because there is a rule that needs enabling and by default it is not.  TMG/ISA was also an issue, because of the way RPC traffic is filtered.  Even if you have a wide-open rule that says “let everything go from spot A to spot B” RPC traffic gets hosed.  Argh.

Suffice it to say, I have finally resolved my issue, and an ISA/TMG specialist will probably think I am a loser, but WTH, here goes.

The problem was that I could not request a cert from the OCS R2 MMC.  The CA was across a VPN (TMG/ISA).  First little bit was finding out that, for security, the Windows Firewall disables COM+ access by default.  Now, you would think, that following the MSFT paradigm of enabling Windows Firewall rules when the feature/role/application is installed, that installing a CA on the server would turn this on, but noooOOOOOoooo!

You have to enable this rule - in my case this was a ws08r2 DC with the EntCA installed on it.  You don’t need to do this on the requestor, but the target of the request.  So, my OCS FE was requesting a cert from the CA on the DC.  Therefore, on the CA, enable the Com+Network Access (DCOM-In) rule:

Then, because of the VPN link involved, on BOTH sides of the link, the rule that allows the traffic from the internal to the VPN target needs to have the RPC traffic filter disabled.  There is a GREAT article here that I found that finally resolved my issue.  This is the piece of that article that did it for me:

Problem: When you request a certificate using the Certificate MMC snap-in, the request fails. This occurs even if the CA is started and you have sufficient permissions to request a certificate.

Workaround: This issue occurs because DCOM is required to acquire a certificate (this issue also occurs if you are using CA Web enrollment).

• If ISA Server is requesting the certificate, disable the "Enforce strict RPC compliance setting" on the system policy rule. To do this, on the Firewall Policy tab of ISA Server Management, click Edit System Policy on the Tasks tab. Select the Active Directory group in the Configuration Groups list. On the General tab, clear the Enforce strict RPC compliance checkbox.
• If an internal host is requesting the certificate from another network through ISA Server, do the following: in the Firewall Policy tab of ISA Server Management, right-click the access rule allowing the traffic, and then click Configure RPC protocol. On the Protocol tab, clear Enforce strict RPC compliance.

What that means visually on the TMG/ISA side :

I hope this helps you in some small way.  Now, back to the job I was supposed to get done this morning!